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( ENTITIES ) 


**The Assumed Guidelines does not represent a guide to the new Unsolicited commercial 
communication Code nor does it replace or supplement its provisions by imposing any new 
rights or obligations on the respective parties. Instead it is designed to complement the new Code 
by suggesting best practice to facilitate positive and productive engagement between all parties 
across a range of issues, roles and responsibilities. Whilst the Code of Practice provides some 
examples of best practice these are not intended to be exhaustive. 


General 


1. Access Provider who adopt this Assumed Guidelines will state so on their respective 
websites. 


2. Access Provider who adopt this Assumed Guidelines may also state so on their contracts. 


3. Access Provider who adopt this Assumed Guidelines has to adopt a Code of Practice for 
all new contracts, and other specified contracts, that are entered into after an effective date 
to be announced by the individual service provider. 


Preamble 


“Access Provider” is committed to the best possible use of its expertise/experience in order to 
satisfy the customers. Exceeding their expectations will always be the first priority in planning 
and delivering telecom services. 


Company Mission 


“Access Provider” believes that prompt response/co-operation is the first step towards 
development of long-term and prospective business relationship. We are committed to Quality 
Services for dynamic growth of the company. 


“Access Provider” is fully committed in fulfilling its Corporate Mission which is that: 


“ “Access Provider’ shall enable the smooth process of acquiring or registering the complaints 
and solving these registered complaints of the customers, and always perceive its services and 
customer’s complaint handling to be of the highest quality. Our customers shall view us as a 
trusted and honest company that always delivers on its promises”. 


Purpose of laying down the Assumed Guidelines for Entity Registration. 
The purpose of laying down the Assumed Guidelines for Entity Registration is to: 


1. Bring uniformity and transparency in the procedures being followed by Access Provider 
with regard to entity registration. 

2. Prescribe standards relating to acknowledgment of time and status of the users registered 
as entity. 

3. Protect the interest of consumers of telecommunication services. 


Review 


The COP, which the Access Provider will create for complaints as given in TRAI regulation may 
be reviewed by the Authority from time to time. The Authority, on reference from any affected 
party, and for good and sufficient reasons, may review and modify this regulation. 


Entity Registration Functionality- 


1. All Entities with associated functions, who will be carrying out given function for effective 
control of unsolicited commercial communication being delivered through them, shall be 
declared by each access provider on their website. 


e Here term “entities” is referred to the telemarketers, firstly telemarketers are required to 
register to access provider through the various forms of registration and submit the fees 
required for registration process. 


e For this purpose, they fill the application form of entity registration, details about their 
purpose of telemarketing and other some important factors. 


2. Each functional entity shall be given unique identity by the access provider to be used to 
authenticate and track the event. After entity’s registration process it will assign a unique id 
by operators to track the events that is happened in operator’s website and also by this id entity 
further register for headers and templates. 


The access provider will determine which type of entity is registered. 


For example, if the telemarketer registered itself for transactional rather than the promotional the 
consent of the subscriber will be checked further rather than the preference, thus, the access 
provider needs to categories the telemarketers. 


All the Access Providers, to which the telemarkerters are registered, shall maintain the records in 
entity register (DL-Entity), and for every entity an entity ID is created which is unique and all the 
access provider shall stored the unique ID in DL-Header including root and sub root of header. 


Entity Register is a Distributed ledger for Entities (DL-Entities) having a record of all entities 
registered to carry out telemarketing related functions with all relevant details. 


When the details about telemarketer’s registration or sign up and verification details of 
telemarketer will be stored in DL-Entity, the session details of entity registration will be send to 
telemarketers through email or message and all the Access Provider must mention the details and 
functionality of the registered telemarketers in their website. 


3. Every Access Provider shall formulate structure and format for headers to be assigned Senders 
for the purpose of commercial communication via sending SMS or making voice call to 
participants. 


And for this purpose it must include the following thing- 


e SMS Header, SMS Header Root, SMS Header Branch for Senders sending Promotional 
SMS, Transactional SMS and Service SMS from 1 1-character alphanumeric strings which 
are not allocated or assigned by Department of Telecommunications for other purpose(s) 
or in accordance to directions of the Authority/ DoT. 


e Calling Line Identity for Senders making Promotional Voice Calls, Transactional Voice 
Calls and Service Voice Calls from 140-level numbering series or any other numbering 
series directed by the Authority/DoT. 


Important Examples of header- 


Telemarketer Header 
PHONPE TM-PHONPE 
SBI BP-ATMSBI 
PAYTM VK-iPaytm 
UBER RM-UBRCHD 
DHBVNL VM-DHBVNL 
Lens kart VM-LNSKRT 


Note for Access Providers- it can be possible that the below stated points may get add up in the 
regulation by the authorities: 


1. headers assigned by RTMs to Principal Entities should be unique. 
One of the entity has suggested Header format as <Name of entity> - <operator><operator 
code><unique 3-digit TM code given>. 


2. first two digits of the header should clearly convey the nature of communication like ‘PR’ for 
promotional communication and ‘TR’ for transactional communication followed by 
organization’s header. 

An increase in the length of header up to 11 digits for covering maximum entities with unique 
headers. 


3. It should be the web- based interface like domain name registration for the header assignment. 
4. Automatically revoking the authorization for headers which remain unused for a period of 6 


months or more. Additional characters should be allowed to be incorporated in the headers to 
avoid proximity match of headers with well-known entities. 


Header Registration Function(HRF)- 


1. To facilitate content provider or principal entity that is the Registered Telemarketer, assign 
header or header root for SMS via Header Registration Functionality, by the operator or through 
its agents, as per allocation and assignment principle and policies, to get new headers . 


Header is an alphanumeric string of maximum eleven characters or numbers assigned to an 
individual, business or legal entity to send commercial communications. 


2. Telemarketer will approach to its operator to get headers assigned on its name. 


e The first process is entity Registration. 
First of all they go to the operator’s website and sign up or register with them to become a 
registered telemarketer. In entity registration telemarketer register with operator and send 
details regarding- 


o Category of content it is going to provide to its customers. 


o Telemarketer provides GST number, related documents for its verification. 


o Secondly, operator involved with telemarketer will check the DL-Entity of it own 
and of other operators if the operator find any complaint regarding telemarketer 
then it show the red flag and does not register the telemarketer otherwise operator 
registers the telemarketer and the telemarketer is marked as RTM. 


The information related to telemarketer’s sign up details and its verification details is stored in DL- 
Entity to recognize that which type of category it belongs to. 


Header root 


Header root is the common substring of block of headers, starting from the first character, sub-root 
of header is the string of header other than header root. It is also known as header branch. Sub root 
of header and entity id is stored in DL-Header along with the service category of RTM in which 
they are working, for example- 


A RTM will be issued different headers according to the service of category they will choose : 
a) Header related to promotion 

b) Header related to transaction 

c) Header related to service 

d) Header related to Government authorities 

e) Header related to well known brands or famous Organizations 


f) Header related to person / business other than above stated points. 


After the selection of service category the RTM will submit the documents and credentials required 
for header registration as per the TRAI regulations. 


Header Registrar: 


Header registrar is an authorized entity responsible for maintaining the header register, header 
registration facility and header verification facility. Its header registrar’s function to register or de- 
register the header for RTM. 


3. The header registrar will carry out verification of documents and credentials submitted by the 
RTM, for assigning the header. 


4. The request of RTM goes to header registrar which maintains header register and the header 
register keep record of headers in DL-Header. Here, header register checks the purpose of header 
and its purpose of sending commercial communications and details of sender to whom it is assigned 
in a safe and secure manner. The whole verification process takes at least seven days to complete. 


5. If request is send by important authorities like Government , or well known brands, famous 
Organizations then an additional authentication process is followed. 


Login Credentials: 


6. The requested header when assigned to the RTM, will bind with mobile number(s) and a mobile 
device of the RTM, in a safe and secure manner, which will be used subsequently on regular 
interval for login to the sessions by header assignee. 


e The assigned headers are important to be attached with the RTM’s mobile number(s) & 
mobile devices to track the details of the RTM if involved in any UCC action or reported 
by various subscribers for spam. 


Additional checks for the authorities: 


7. The Header registrar has to carry out additional authentications in case of a request for headers 
to be issued to SEBI registered brokers or other entities specified by Authority by directions, 
orders or instructions issued from time to time. 


8. The Header registrar has to carry out additional authentications in case of a request for headers 
to be issued to government entities, corporate or well-known brands, including specific 
directions, orders or instructions, if any, issued from time to time by the Authority. 


e In this whole process, when RTM requests for header, then header registrar in the 
verification process checks that if the Request is sent by the SEBI registered brokers / 
Government authorities / Important organizations or not. 

e And if request is sent by these authorities, the relevant operator will add one extra step 
in authentication process and send a confirmation message to these authorities to 
confirm that header request is sent by them or not. 


For example, say Ministry of HRD wants a header, they will apply for header request 
submitting all the relevant data and documents and now during the verification process a 
confirmation message will be sent by the access providers to HRD to confirm that the header 
request is sent by them only. 


When the HRD confirms the request, the header registrar will assign the header to Ministry 
of HRD according to the directions issued by the TRAIL. 


Additional checks for look-alike headers: 


9. The Header registrar has to carry out additional checks for look-alike headers which may 
mislead to a common recipient of commercial communication, it may also include proximity 
checks, specifically in case of government entities, corporate, well-known brands while 
assigning headers irrespective of current assignments of such headers, and to follow specific 
directions, orders or instructions, if any, issued from time to time by the TRAL. 


For example, if TM-PAYT is the header of paytm for telemarketing and now another company 
whose name is Paytamy requests to assign header for them, as we know, in header assigning 


process some initial alphabet of company is taken, the header registrar concentrateon the header 
already assigned to paytm and ensures that this is not going to be assigned to paytamy. 


Here, Header registrar ensures that every header is unique and no single header is assigned to the 
different RTMs. 


So they assign header to paytamy according to access operators software and change some initial 
alphabet to ensure that header is not same as paytm. Access providers may include additional 
characters in the headers to avoid proximity match of headers. 


Header format and Structure- 


e Mostly service provider suggested that a header is length of up to 11 characters and it is of 
type XX-AAAAAABBB. 


e In this XX are the initials of operator’s name and circle from where message is transmitted. 


For example, if operator is airtel and message is transmitted from pune then XX takes A from 
airtel and P from pune and its mean is AP. 


e AAAAAA takes initial six character from telemarketer’s company. For example, paytm in this 
initial six character include whole paytm. So in this AAAAAA means paytm. This initial 
AAAAAA character is called root of header and it is stored in DL-Header. 


e BBB takes the three initial letter of category of content choosen by the RTM while registering 
the header. 


For example, paytm send advertisement related health then BBB takes up the unique 3-digit TM 
code of health. The BBB is called as subroot of header and it is also stored in DL-Header. 


e If paytm sends an advertisement related to health from airtel operator from its pune branch 
then header could be like, AP-PPAYTAMO91. 


e Until now, the code for ‘BBB’ was not followed by the TRAI and companies were sending 
the messages to customer related to each and every product they can. Now, by assigning 
‘BBB’ to the companies or telemarketers, the RTM could only send messages to customer as 
per there consent or there preferences related to advertisement. 


e HRE assign header or header root for SMS where header root means the common sub string 
of block of headers, starting from the first character. 


Consent Registration Function 


Access provider will give access to customer for taking the consent. The registration function will 


be done through any online portal. 


a) If the customer is already registered on portal. He/she can go directly for Log-in option but 
if not existing user they have to fill up the mandatory fields which will be 


e First & Last Name 


e State 
e Country 
e Zip Code 


All this information needs to be stored on OAP database. The clearest way of obtaining 
consent is to invite the customer to tick an opt-in box confirming that they wish to receive 


marketing messages via specific channels. 


b) Consent Template will be shown to customer. Each Consent Template is accessed by a 
unique URL so that it can be easily referenced as one additional field with each lead record 


in the DL-Consent. Consent Template will include the fields like 


Consent Template 


Type and Timestamp OTP Telephone Consent Validity of 
Purpose of Verification Number Acquirer consent 


Consent Status 





Once it is presented as a complete authoritative document, it can be easily printed or passed 
along to the appropriate parties as needed. The crucial consideration is that the individual 
must fully understand that their action will be taken as consent, and must fully understand 
exactly what they are consenting to. There must be a clear and prominent statement 
explaining that the action indicates consent to receive marketing messages from that 


organisation. It should also indicate that: 


e The personal information may be used by Access provider or its subsidiaries or 
affiliates to market other products. 


e Describe the type of product or service that might be marketed to customer. 


Data users are reminded not to design a service application form in such a way that renders 
it impracticable for its customers to refuse the use of their personal data for direct marketing 


purposes. 


Telemarketer should collect the following information when the customer visits on webpage: 


C) 


d) 


e) 


Date and time of the consumer’s visit to the web page 

URL where the consumer completed the form. 

The IP address, browser and operating system of the visitor who submitted the form 

A complete copy of the HTML and images of the web page where the consumer filled out 
his/her information. This is important to be able to interact with the web page as it existed 
at that point in time and allows for real-time page scanning for disclosure language. 

There must be some form of communication or positive action by which the individual 
clearly and knowingly indicates their agreement. This might involve clicking an icon, 
sending an email, subscribing to a service, or providing oral confirmation. The customer 
must have a genuine choice over whether or not to consent to marketing. Organizations 
should not coerce or unduly incentivize people to consent, or penalize anyone who refuses. 
Once the consent template is completed. Customer authentication will be done be sending 
OTP. OTP will be send to customer by his/her particular access providers. There will be 
two options of sending OTP either by Call or Message. 

After authentication is completed it should be stored on DL-Consent. All the personal data 
will be collected from customers .Since personal data are of different degrees of sensitivity 
in different contexts, access providers should establish a data classification policy which 


suitably classifies the various kinds of personal data they hold, based on their degree of 


g) 


sensitivity and risk of exposure. The information collected from customer i.e. Contact 
number needs to be valid for 30 days. 

Protocols should be in place to ensure that the consent process has been completed, that 
there is valid consent and that the decision has been properly recorded. 

The consent can be revoked by the customer at any point of time. The practicalities of 
withdrawing consent and the implications of doing so should be made clear. There must be 


an effort to determine the reasons for withdrawal of consent. 


Step 1: Login to registration 
Portal/mobile app and initiate 
registration 


Step 2: Capture all relevant 
information 


Step 3: Assess and verify the 
information 


Step 4: Certificate is issued and 
saved as unique 





By signing this membership application form, 
you agree that STRSTR -2y 
collect, use and disclose your personal data 
as provided in this application form, or (if 
applicable) as obtained by our organisation as 
a result of your membership, for the following 
purposes in accordance with the Personal Data 
Protection Act 2012 and our data protection 


oli (available at our website 


(a) the processing of this membership 
Date: - ; _ application; and 


(b) the administration of the 
membership with our organisation. 


Please visit our website at ic) <webpage URL> for further details on our 
data protection policy, including how you may access and correct your 
personal data or withdraw consent to the collection, use or disclosure of 
your personal data. 


Example of getting consent from customer 


| withdraw my consent to the use and disclosure of my personal data for receiving 
marketing matenal as follows*: 


* Please tick the relevant boxes below to indicate the categones, and corresponding medium of 
communication, of the marketing materials for which consent is withdrawn. 


o Your organisation’s monthly newsletter (sent via email) 

& Information about your organisation’s products and services, including updates 
on the latest promotions and new products and services, via the following 
channels: 

a Email 
a Text Message 
a Phone Call 


2 Information sent by your organisation on third parties’ products and services, 
such as updates on their latest promotions and their mew products and services, 
via the following channels: 
a Email 
a Text Message 
a Phone Call 





o The use of my contact details by third parties** to send me information 
on their products and services, via the following channels: 
a Email 
a Text Message 
a Phone Call 


** Third parties that our organisation had disclosed your personal data to for this purpose will be informed 
of your withdrawal of consent and your personal data will no longer be disclosed to any third parties 
from the effective date of your withdrawal. 


Example of withdrawn of consent 


Consent Register means a Distributed Ledger for Consent (DL-Consent) having all relevant details 


of consent acquired by sender, in a secure and safe manner, to send commercial communications 


and may be required for the purpose of pre and post checks for regulatory compliance based on the 


consent. 


Consent Registrar or CR is an authorized entity under relevant regulations responsible for 


maintaining the consent register, customer consent acquisition facility and customer consent 


verification facility. 


Consent Registrar 


a) In Consent Register there will be the details of the users which will be placed in safe and 


secure manner. Consent register will be stored in DL-Consent and will have the following 


columns - 


Telephone number of customer in international numbering format 
as referred in National Numbering Plan 

Header of Sender(s) or Consent Acquirer(s) against which consent 
is taken 

Day & Time when consent was taken 

Validity period of consent 


Type and purpose(s) of consent 


b) Different telemarketers require different types of access (e.g. read only, read write) to 


different types of personal data. Providing a telemarketer with access rights that exceed 


what he or she is required to enable him or her to carry out his or her daily business 


operations creates an unnecessary opportunity for abuse. There must be an access control 


policy setting out the levels of authority and the associated types of access rights for each 


category of personal data. In general, access to data should be given on the basis of a 


practical application of the “Need-to-know” principle. 


Establish Customer Consent Acquisition Facility (CCAF), to record recipient’s consent to 


receive commercial communications from the sender or consent acquirer. 


c) Registrar must provide information to customer in a form that is easy to understand, 


providing explanations for abbreviations and codes. Customer consent verification facility 


will give the rights to the customers for Verifying — At the time of submission of details 


there should be pop of Please check the details once again before final submission. After 


final submission details should be shown on the profile of customer. 


Modifying -Once after the final submission only the field Types of service you wish to receive 


should be able to change. 


Renew and Revoke- Customer can even delete their details and even subscribe to the DND 
service. Clear and transparent means of unsubscribing to and withdrawing consent to 


receive future messages. Revoke consent by: 
i) Sending SMS to short code 1909 with Label <Revoke> and <Sender ID> or to telephone 
number mentioned in the message or during the voice call received from the sender(s). 


ii) Calling on 1909 or number mentioned for revoking the consent during the voice call 
received from the sender(s) or 


ii) Calling on customer care number or 
iv) Interactive Voice Response System (IVRS) or 


v) Mobile app developed in this regard either by the Authority or by any other person or 
entity. 


vi) Approved by the Authority or 
vii) Web portal with authentication through OTP or 


viii) Any other means as may be notified by the Authority from time to time. 


If any complaint arises the access provider can access the data from DL-Preference 


)) 


k) 


I) 


Personal information shall be as accurate, complete and up-to-date as is necessary for the 
purposes for which it is being used. There should be updated database every second because 
every entry needs to be available at Consent Registrar side. The Consent Registrar should 
have the access to insert, modify or delete the data but the others like telemarketers just 
have the access to read the data. Different protection measures can be used for data like of 
log in and password to specific users. 

In case of explicit consent, recorded consent must be available as a part of consent register. 
Inferred consent is not explicitly recorded in consent data and not to be extended beyond 
12 months. 


The ledgers need to be available at Access providers, Telemarketers and Consent Registrar. 


m) If any revocation is done by access provider or telemarketer due to any reason it should be 


specified in DL-Consent. To remove the recipient's contact information (telephone number) 


to which the message was sent from the consent record(s) corresponding to the sender for 


1) 


)) 


k) 


1) 


all purposes requiring explicit consent except in case specific purpose(s) 1s indicated by the 
customer during revocation of consent from the consent register within 1 business day. 
When the customer submits the detail a message should be send to consent registrar that 
new user is added. 

Requirements of consent and revocation of consent, details for handling consent needs to 
be stored in COP-Preferences. 

Pre check is performed at time for retrieving the information from database and post check 
is performed to verify the authenticity of recoded consent. 

Machine Learning (ML) techniques would help to match the type and category of content 
being delivered with the interest area of the customer who has exercised option for 


preference or has given consent. 


m) With permissioned private DLT networks there is an inherent trust as the users must be 


n) 


0) 


P) 


1) 


li) 


given consent by a governing body or entity to participate in that DLT network. 
Verification of consent(s) by comparing the target telephone number(s), category of content 
with the list of telephone numbers and consent(s) given by the recipient to the sender in the 
Distributed Ledger for Consent (DL-Consent). 

Register existing consents on Consent Register. Register existing consents with consent 
registrar in robust manner to make it non-repudiable, fix deadline for expiry of consent not 
registered with consent registrar. 

Register new consents on consent register as prescribed in relevant regulations or schedule 
or directions 

Develop Application Program Interfaces (APIs) for Senders to recording consent with user 
agent or application client available on a mobile device or enterprise system. 


Broadening of installation and active base of consent acquisition application client. 


Scrubbing Function 


a) 


Initially, using data from existing register for customers’ preferences 

subsequently, using records of DL-Preferences 

Then using records of DL for Header Register 

Then introducing virtual identities and tokens among entities to access real identities 

Then using records of DL for consent 

Telemarketer will tell consent registrar which contact details are needed. Preferences will 
be set by the customer in the consent registration template. The data will be sorted out and 


provided according to the preferences to the telemarketers. 


b) When the data will be given to the telemarketer it will include Contact, Date and Time fetch 
from DL-Consent. Date and time data is given so that they can only send the message to 
the customer according to the preference time and day set by the customer. 

c) Consent register and preference register will have id and password and it will be shared 
among authenticate persons. 

d) Making available relevant details of scrubbed list to corresponding OAPs and TAPs for 
carrying out reverse mapping of virtual identities to real identities for further delivery. 

e) To identify and report probable instances of request received for scrubbing of list of phone 
numbers collected through harvesting software or instances of dictionary attack to relevant 
entities authorized to take action. 

Dictionary attack- The use of random number generators or address harvesting software to 
generate telephone numbers, IM identifiers or email addresses for sending commercial 
messages (including robo calls). 

e Scrubbing is to be used as service model for protection of customer data. 

e Minimum (x) charges may be applicable for carrying out scrubbing or there may be one- 
time charge. 

e Safety and security may be provided in a multi participant environment with peer to peer 
and distributed environment approach. 

e Inferred consent is not explicitly recorded in consent data, and therefore, cannot be checked 


for in the scrubbing process. 


Content Registration Function 


Telemarketers Communication Classification 


Telemarketers 
communication 
classification 





This category includes all This category includes all 
Banking alerts, CRM promotional and marketing 
communication & others communication 
| | 
* Voice calls: any number * Voice calls: Only 1400XX 
series series 
= SMS channel: “XY-alpha” * SMS channel: “PQ-Y12345” 
where Y is the customer's 
preference code 


Here the Transactional Communication can be defined as, 


e Information pertaining to the account of its customer sent to the customer by a licensee 
or Bank or financial institution or insurance company or credit card company or 
depositories registered with Securities and Exchange Board of India or Direct to Home 
Operators, or 


e Information given by Airlines or Indian Railways or its authorized agencies to its 
passengers regarding travel schedules, ticket booking and reservation, or 


e Information from a registered educational institution to its students or their parents or 
guardians. Any message transmitted by or on the directions of the Central 
Government or State Government, TRAI or any agency authorized by TRAI, or on the 
directions of bodies established. 


The communication held other than the type of transactional communication stated above 
than it comes under the promotional or marketing communication. 


Content Template 


The content template for which an RTM can register for header to its operator is divided into 
following two categories: 





Content Template +} ..— .-— -.— .. 


Content Template for Transactional 
Communication 


Content Template for Promotional or 
Marketing Communication 





Content Template for Transaction 

A template of content registered by any RTM with the access provider for sending 
transactional message, service message or transactional voice call, service call for the 
purpose of commercial communication and contains content which may be a combination 
of fixed part of content and variable part of content, where 


o fixed part of content is that part of content which is common across all commercial 
communications sent to different recipients for same or similar subject; 


© variable part of content is that part of content which may vary across commercial 
communications sent to different recipients for same or similar subject on account 
of information which is very specific to the particular transaction for a particular 
recipient or may vary on account of reference to date, time, place or unique 
reference number; 





Content Template for Transaction 











Fixed Part Variable Part 
Ex: Your account balance is Ex: Balance amount according to account 
holder 











Content Template for Promotion 

A template of content registered by any sender with the access provider for sending 
promotional message or promotional voice call for the purpose of commercial 
communication and contains content which is fixed content and common across all 
commercial communications sent to different recipients for same or similar subject. 


Content Template Registrar (CTR): 


Content Template Registrar is an authorized entity responsible for maintaining the content register, 
content registration facility and content verification facility. Its Content Template Registrar’s 
function to register or de- register the content template for RTM. 


The Content Template Registrar will establish and maintain the Distributed Ledger DL- 
Content Register. 


The Content Template Registrar will carry out content template registration function. 

o A RTM is required to register for the content template in order to facilitate its 
customers. The content registrar does the registration process for the RTM and 
maintains the records and data for the future use if required by TRAI as general 
audit. 


The Content Template Registrar will keep the records of registered templates in immutable 
and non-repudiable manner. 


The Content Template Registrar will maintain the minimum performance requirements as 
specified by the TRAIT. 


The Content Template Registrar will perform any other function and keep the relevant 
details required for carrying out pre and post checks for regulatory compliance. 


Content Template Registration 


1. 


The RTM will register for the content for commercial communication, according to their 
requirements. 


The RTM will register through the access provider’s website. 


The RTM authenticates via OTP send to his registered mobile number and obtain the 
registration number. 


The telemarketer chooses the required content template according to his requirements. 
The telemarketer’s request is handled by Content Template Registrar. 
The RTM can register for the required content template for communication purpose for: 


a. content template for transaction (service) SMS or Voice Call and/or 
b. content template for promotion SMS or Voice Call. 


Following labels should be prefixed by the access provider to the text of commercial 
communication: 

e Label <Transactional> in case of Transactional Message; 

e Label <Service> in case of Service Message; 


e Label <Promotional> in case of Promotional Message; 


Labelling to categorize content and From: HEADER 
informing to customer that it is promotional <Promotional> 


Toll Free Number for 
revoking consent 


Header or Telephone Number From which 
which Commercial Communication was 


ie, From: HEADER 


<Transactional> 


Transactional messages sent as inferred <consent 
consent may be identified inferred: inquiry 
for the product> 


received 





8. Also, the RTM should make sure that the promotional SMS/Call belonging to a category 
shall contain information only related to specified content category he subscribed for and 
shall not mix any other information with it. 


9. While registering templates, type, nature and length of content may be checked so that it 
does not contain material for promotional purposes. 


10. The RTM can call or message the customer from the list of customers who are subscribed 
to services by obtaining the list from the Operator. 


11. The assigned content templates are stored in a distributed ledger, to keep the record of the 
content for which a RTM is assigned. 


12. The registrar verifies the document of the RTM. 


13. After verification of the documents the content registrar stores the details of record of the 
RTM or the entity with the assigned content template. 


Content Template Registration Function (CTRF): 
The CTRF will carry out the following functions 


i. The content template registrar will check content of the template being offered by RTM for 
registration as a transactional/service template or promotional template. 


il. 


lil. 


iv. 


Vi. 


Identify fixed and variable portion(s) of the content in the offered transactional template 
and service message template with identification of type of content for each portion of 
variable part of the content, e.g. date format, numeric format, name of recipient, amount 
with currency; reference number, transaction identity; 


To estimate the total length of variable portion, viz. total length of fixed portion for a typical 
transactional message, service message for offered template; 


Categorization of content needs to be carried out in such a manner that it can be matched to 
the scope of consent. This may require registration of content templates. There may be 
multiple templates for consent and content depending upon the situation and the context. 


Templates may be required to be registered separately for each regional language or 
combination of multiple languages. 


There may be separate templates for awareness programs or messages to be sent on the 
instructions of Government or Statutory bodies and such messages would be considered as 
service messages. Templates may also be registered for voice calls in form of scripts and 
transcripts. 


To de-register template or temporarily suspend use of template; 


e The Content registrar can deactivate or temporarily suspend the template of specific 
telemarketer by verifying the database of other operators. 


e Incase recipient receives content that he or she was not expecting against the consent 
given to the sender, there would be option to revoke such consent. In case of any gross 
misuse of consent and content templates, access providers may suspend the consent 
acquired under disguise or de-register the corresponding content templates. 


To generate one-way hash for fixed portion of content of template and ways to extract fixed 
portion and variable portion(s) from actual message for carrying out pre and post checks of 
actual content of actual message offered for delivery or already delivered; 


e pre check of message content: Verifies whether the content of the message is 
relevant to the context of the content category the RTM is subscribed for. 


e Commercial communications related to promotions may also be divided on basis of 
category of content. Using content templates would help to consider content type 
and scope of consent while delivering and applying pre-checks for regulatory 
compliances. 


e The technique employed to carry out the pre-check of actual content of actual 
message for delivery is Machine Learning (ML). 


e Machine Learning (ML) technique help to match the type and category of content 
being delivered with the interest area of the customer who has exercised option for 
preference or has given consent. 


N-Dimensional Space of 
High [ie interest Area 
wrurment yy ® Preference of Customer 


© Content Category 





( : > Interest Area and Content Category 
in terms of probability of Overlap 






Illustration for matching interest area of the customer with category of content 
vii. To check content of the template being offered for registration as a promotional from 
perspective of content category; 
villi. Assigning unique template identity to registered template of content; 
ix. The CTRF generates the activity logs for the actions performed. 
x. Verification of preference(s) by comparing the target telephone numbers, category of 
content with the list of telephone numbers and preference(s) of category of content by the 


target recipient customer in the Distributed Ledger for Preference (DL-Preference). 


xi. These activity logs are recorded as a proof of the action that has been performed. 


Transactional / Non-Commercial Communication 


1. Other than purely Non-Commercial information, a Non-Commercial Communication may 
only include all or any of the following information: 


e Comment directly related to the Non-Commercial information; 
e Name, logo and contact details of the Message Authorizer or Telemarketers; 


e The name and contact details of the author; 


e The name, logo and contact details of the author’s employer (if applicable); 


e If the author of the Non-Commercial Communication is a partner in a partnership — the 
name, logo and contact details of the partnership; 


e If the author of the Non-Commercial Communication is a director or officer of an 
organization the name, logo and contact details of the Organization; 


e If the message is sponsored, the name, logo and contact details of the sponsor; 


e If desired, a Functional Unsubscribe Facility. 


Example for Non-Commercial Communication 


Message from a private law firm, which includes an information sheet outlining the effects 
of a particular court decision. At the bottom of sheet, the law firm may have the firm name, 
address, contact details and logo. This message could be seen to be commercial in nature 
as ultimately the message is designed in some way to promote the interests of the private 
law firm. However, as the message only contains factual information plus the allowable 
contact information it would come within the definition of a non-commercial 
Communication; 

an electronic version of a neighborhood watch newsletter which is sponsored by the local 
newsagent; 

an electronic newsletter from the local chamber of commerce which is sponsored by one of 
its members; 

an e-mail message promoting a birdwatching enthusiasts’ website with a link to the website, 
where the website provides purely factual information relating to birdwatching but is 
sponsored by a commercial entity. 


Content Template for Transactional Communication 





Examples for Probable Templates }@ 
inferred Consent Transactional SMS Templates 


TL-HEADER 


Hello! Your A/c no.< > has been debited by 
>on <DD/MM/YY> The A/c balance is 


Thank you for using <...PRODUCT.. > Card No < 
>on <DD/MM/YY> for INR < 


> Info: <TYPE>/ <PURPOSE>/ <... 
Transaction Id or Reference Number....> 


check EMI eligibility on spends above INR < 
log on <...URL...> T&C Apply. 





Examples for Probable Service Templates ia 
Explicit Consent 


Service SMS Templates 


Welcome to ..COMPANY.. referral program, Multiply! Share 
your coupon code <....> and get <...BRAND...> vouchers 
worth up to Rs. <....>! Discover more -<.....URL...> 


Dear <..NAME..>, Your ...PRODUCT.., <...PRODUCT 
ID..> is due for Service on <..DD/MM/YYYY..>. Visit <... 
URL...> or contact your nearest BRAND or COMPANY 
Dealer for appointment. We look forward to serve you! 


Upgrade to <......> Bank Privilege Credit Card and get 
> vouchers of more than Rs <. > airport lounge 
access & more. Call now on <1800- >T&C apply 


Now transfer funds 24/7 with <...ENTITY. > Bank IMPS 
: even on a bank holiday. Use <... SERVICE NAME.. > 
TSP NAME TARIFF PLAN- Rs <.... > Get daily <.> GB Internet , Mobile or SMS banking to transfer funds. T&C. 
DATA, UNLIMITED Free Local & STD calls, Free <...> 


SMS on any N/w for <...> days. T&C apply". For details dial 


<... TELEPHONE NUMBER....> ; : = ; ” 
Gifta< > to your family and friends this holiday 


season with <....> .Bank Cards. Book now on <...URL... 


All Residents are requested to login to ... URL... and >T&C apply 


participate in survey for MONTH/ YEAR on maintenance 
services. 





* Text in Capital Letters may be important for Categorisation of Content, relationship of Source & sender 


Promotional / Commercial Communication 


The RTM provides the category of content during the registration for promotional messages, that 
is in which category it wants to promote the business. 


The category of content is as follows: 





Category for Commercial Communication (Promotional & Marketing) 





Banking/Insurance/Financial products/ Credit cards 
Real Estate 

Education 

Health 

Consumer goods and automobiles 
Communication/ Broadcasting/ Entertainment/ IT 
Tourism and Leisure 

Food and Beverages 
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1. RTM must ensure they do not send, cause to be sent or authorise the sending of Unsolicited 
Commercial Communications. 


2. RTM may send, authorize the sending or cause the sending of Commercial 
Communications to Recipients or Relevant Electronic Account Authorities providing that: 


a. The Recipient has provided Express Consent to receive such Commercial 
Communications. 


b. It can be reasonably Inferred through conduct of the Recipient that the Recipient 
has Consented to receive such Commercial Communications (Inferred Consent); or 


c. It can be reasonably Inferred through the business and other relationships of the 
Recipient that the Recipient has Consented to receive such Commercial 
Communications (Inferred Consent); or 


d. The Relevant Electronic Account Authority has provided Express Consent on behalf 
of the Recipient to receive such Commercial Communications . 


e. It can be reasonably Inferred through the conduct of the Relevant Electronic 
Account Authority that they Consent on behalf of the Recipient to receive such 
Commercial Communications (Inferred Consent). 


3. Inferred Consent will be deemed to exist if the RTM can show that: 


a. The Recipient or Relevant Electronic Account Authority has an existing and 
continuing relationship with the RTM or Message Authorizer, as an identified; 


* customer; 

* account holder; 
* subscriber; 

* member; 

* licensee; 

* registered user; 
* employee; or 

* contractor; 


and would have a reasonable expectation of receiving such Commercial Communications; or 


b. There is no ongoing relationship however there is the potential for one and by their 
conduct the Recipient or Relevant Electronic Account Authority has taken an active 
step to provide their contact information and has not withdrawn Consent within the 
last two years with the reasonable expectation that they may receive Commercial 
Communications and would have a reasonable expectation of receiving such 
Commercial Communications; or 


c. There is no ongoing relationship however there is the potential for one and by their 
conduct the Recipient or Relevant Electronic Account Authority has taken an active 
step to provide their contact information and has not withdrawn Consent within the 
last two years with the reasonable expectation that they may receive Commercial 
Communications the Recipient’s work-related Electronic Address has been 
conspicuously published in the public domain in circumstances where the job 
function or position of the Recipient is readily apparent; and 


i. The Commercial Communication is being sent to the Recipient in their 
business or Organizational capacity; and 


ii. The Commercial Communication relates to the business/Organizational 
functions or duties of the Recipient; and 


iii. The Recipient, or organization in which the Recipient holds a job or position 
has not specifically indicated within the publication that they do not wish to 
receive Commercial Communications (or has not provided notice of its 
refusal or withdrawal of Consent to Commercial Communications being 
sent to the Recipient’s Electronic Address). 


4. The process that RTM and Message Service Providers employ to gain Consent from the 
Recipient or Relevant Electronic Account Authority must be clear and transparent. 


5. Where at any time a Recipient or Relevant Electronic Account Authority has expressly 
notified the Message Authorizer, Telemarketers or Message Service Provider that Consent 
is withdrawn or denied, the Telemarketers or Message Service Provider must not rely on 
circumstances which might otherwise be considered Inferred Consent to send a Commercial 
Communication. 


Example. Commercial Communications sent on behalf of Charities, Religious Organizations, 
Government Bodies and Registered Political Parties. It also does not apply to Educational 
Institutions that are contacting the households of current or former students about the institution’s 
own goods and services. 


Examples for Probable Promotional Templates wa 


TL-HEADER TL-HEADER TL-HEADER 


Lose weight naturally! Latest in COLLECTION Did you know TYPES OF PRODUCTS 
Get MY DIET by <NAME OF <..SEASON or YEAR...> now ata are in? Get styling tips & more with 
CONSULTANT> & lose upto TRADE or BRAND NAME store your Personal Shopper. Visit your 
No Machine.No exercise. near you. Shop now to upgrade nearest store or call <... TELEPHONE 
First FREE consultation Click your wardrobe. T&C Apply. NUMBER...> to book your 
appointment and make shopping 
during the Shoppers Stop Up To <... 
HHOWROOMS FOR SALE!! - 
oe an i ain "SALE SALE" GET UPTO <...>% >% Off Sale effortless. T&C Apply. 
RANGE ....> Crores OFF ON SAREES, SUITS, 
RETURN- <....>% LEHNGA, SHAWL, GOWN & Celebrate this <...FESTIVAL..> in 
TENANT- INTERNATIONAL READYMADE SUIT. COMPANY COLLECTIONS-1 from BRAND or 
BRANDS <STORE ADDRESS> TRADE NAME at Rs. <...> onwards & 
LOCATION, CITY <.. TELEPHONE NUMBER..> COLLECTIONs-2 at Rs. <...> onwards 
Call - <TELE PHONE NUMBER..> HURRY SALE FEW DAYS MORE only at Shoppers Stop. Grab one 
NOW!! T&C apply 


Redeem your <...POINTS...> COMPANY SALE!! Avail <...>% Off 
COMPANY Rewards points before on all products!Special offer <...>% COLLECTION <.YY..> now ata 


Latest in <..SEASON...> 


| Sh tTh off on select products!Contact- 
rin Hr OUTLET tthe <.. TELEPHONE NUMBER..> pclae oO — weak ny yg 
COLLECTION RANGE T&C <.-URL....> Now 7 Days Open. proc ici iil a 





Content Verification System: This will allow screening of content being sent RTMs to weed to 
promotional message or other messages the customer hasn’t given consent to receive. It can also 
help in ensuring the content meets regulatory stipulations. 


Content Format and Type Verifiers (CFTV): Functional entity should be set up by Access 
Provider to carry out content verification; keep records with all relevant details for future 
references. 


Content Verification Function (CVF): to identify the content type and category of messages to 
be delivered or already delivered via an automated tool or utility software. 


Honeypots are deployed at the time investigations of complaints to verify the compliance with 
regulations. 


ASSUMED GUIDELINES : 2 


(PREFERENCES) 


**The Assumed Guidelines does not represent a guide to the new Unsolicited commercial 
communication Code nor does it replace or supplement its provisions by imposing any new 
rights or obligations on the respective parties. Instead it is designed to complement the new Code 
by suggesting best practice to facilitate positive and productive engagement between all parties 
across a range of issues, roles and responsibilities. Whilst the Code of Practice provides some 
examples of best practice these are not intended to be exhaustive. 


General 


4. Access Provider who adopt this Assumed Guidelines will state so on their respective 
websites. 


5. Access Provider who adopt this Assumed Guidelines may also state so on their contracts. 


6. Access Provider who adopt this Assumed Guidelines has to adopt a Code of Practice for 
all new contracts, and other specified contracts, that are entered into after an effective date 
to be announced by the individual service provider. 


Preamble 


“Access Provider” is committed to the best possible use of its expertise/experience in order to 
satisfy the customers. Exceeding their expectations will always be the first priority in planning 
and delivering telecom services. 


Company Mission 


“Access Provider” believes that prompt response/co-operation is the first step towards 
development of long-term and prospective business relationship. We are committed to Quality 
Services for dynamic growth of the company. 


“Access Provider” is fully committed in fulfilling its Corporate Mission which is that: 


“ “Access Provider’ shall enable the smooth process of acquiring or registering the complaints 
and solving these registered complaints of the customers, and always perceive its services and 
customer’s complaint handling to be of the highest quality. Our customers shall view us as a 
trusted and honest company that always delivers on its promises”. 


Purpose of laying down the Assumed Guidelines for Preference Registration. 
The purpose of laying down the Assumed Guidelines for Preference Registration is to: 


4. Bring uniformity and transparency in the procedures being followed by Access Provider 
with regard to preferences registered by the users. 

5. Prescribe standards relating to acknowledgment of time and status of the preferences 
registered by the users. 

6. Protect the interest of consumers of telecommunication services. 


Review 


The COP which the Access Provider will create for complaints as given in TRAI regulation may 
be reviewed by the Authority from time to time. The Authority, on reference from any affected 
party, and for good and sufficient reasons, may review and modify this regulation. 


Customer Preference Registration Facility (CPRF) 


It shall be established and arrangements made must be followed by every Access Provider to 
facilitate customers, on 24 hours X 7 days basis throughout the year: 


a. Access Provider shall provide ways and means to record consent or record revocation 
of consent of customers related to Commercial Communication and exercise his 
preference(s) from the list(s) of choices for: 

- Preference(s) of categories of Commercial Communication. 


- Preference(s) of the mode(s) of communication, 


- Preference(s) of time band(s) and types of day(s) of the week including public 
and national holidays. 


b. Access Provider shall provide following modes, free of cost, to the customer, as per his 
choice, to register, modify or deregister preference(s): - 


- sending SMS to short code 1909 
- calling on 1909 


- Interactive Voice Response System ([IVRS) 
- sending USSD 


- Mobile app developed in this regard either by the Authority or by any other 
person or entity and approved by the Authority 


- Web portal with authentication through OTP 


- Any other means as may be prescribed by the Authority from time to time. 


c. Access Provider shall duly acknowledge the receipt within 5-10 minutes of the request 
made by the customer for registering, modifying, deregistering the preference with 
unique reference number 


»» Procedure for registration or change of preference of Categories of content for 
Commercial Communications. 
Customer can opt-in/ opt-out for any or all Commercial Communications Content 
categories of content: [To Unblock/Block] 


Commercial Communications 
Category to be unblocked/blocked | ‘V5 Calta | SMS: Send SMS to 
or opted infopted out 1909 following 


Subscriber choosing the option of 
type of change itwants inits | 5+ In fOpt-Out| Opt-in fOpt-Out Opt-In /Opt-Out 
preferences. 
Al OC Categories (to be 
UNBLOCK) FULLY | *#19097908) *1909*0# 
ALL BLOCK 


unblocked/blocked) except 
UNBLOCK) BLOCK | *#1909"514| *1909"508 
SERVICE | PROMO 


transactional type of commercial 
UNBLOCK *#1509"91R) *1909"18 
ai 
UNBLOCK *#1909"928] *1509°28 
92 
UNBLOCK 1909*928] *1909*3# 
35 
UNBLOCK 1909948) *1509"4# 
94 
UNBLOCK 1909*95s] *1909"5s 
35 
1909*968 
1909*97# 
1909*938 


communications 
All OC Categories to be 
unblocked except Promotional 
/blocked except transactional 
and service type of 
commercia! communications 


liganking/Insurance/Financial 
products credit cords, 


(ii)Reol Estate, 


Wieansumer goods and 
qutomabiles, 


(Vilcommunication/Bracdcasting 
Entertainment, 


UNBLOCK *1509"6# 
36 

UNBLOCK *1909*7# 
Fl 

UNBLOCK *1909"8# 


3a 
Table-1 shows the list of content categories available as choices for preferences and the 
methods to unblock/block those content categories which includes — IVRS, SMS, USSD. Using 
any of the method provided, subscriber can unblock/block their preferences for mentioned 
content categories for commercial communication. 


(vil) Tourism and Leisure, 


*# 
*# 
*# 
*# 
*# 

# 


(VililFood and Beverages; 





lililEqucation, 


Table-1 (Category of Content) 


Provide 24*7 service to the Subscribers for registering preference(s) for 
Commercial Communication and maintain complete and accurate records of 
preference(s). 


On receiving the request in the form of call/message/USSD-string (as specified in 
the Table 1) from the customer/subscriber, generate unique request number 
(URN) and process the request. 


Subscriber should be notified by SMS comprising Unique Request Number 
(URN), timestamp of request, list of content categories to unblock/block, access 
provider name. 


Update Distributed Ledger for Preferences (DL- Preference) within ‘X’ time. 


After updating DL-Preference, communicate to subscriber with “Confirmation 
and Final Status along with options to block/unblock opted preference(s) of 
content categories for commercial communication”. 


Subscribes shall be communicated for the Lock-in Period of requested preference 
categories with effective timestamp. 


In case of communication with customer executive of Customer Care Center, 
preference to opt-in/ opt-out may be communicated. 


FULLY BLOCK option shall put the customer in Fully Blocked state and block 
services as well as promotional types of commercial communications for all 
categories of content, mode, time band and day types. 


UNBLOCK ALL option shall put the customer in Fully Unblocked state and 
unblock services as well as promotional types of commercial communications for 
all categories of content, mode, time band and day types. 


BLOCK PROMO option shall block only promotional types of commercial 
communications for all categories of content except service and transaction type of 
commercial communications. 


UNBLOCK SERVICES option shall unblock all service and transaction type of 
commercial communications except promotional types of commercial 
communications for all categories of content. 


The Authority may, from time to time, add or remove number of categories, or sub- 
categories for content. The solution is flexible and scalable and should be be updated 
with the changes within “X’ business days. 


»> Procedure for registration of preference or change of preference of Mode for Commercial 
Communication 


Customer can opt-in/opt-out of any or all of following categories of mode(s) of 
communication [To Unblock/Block]. 


UCC Mode of IVRS: Call to 1909 SARS: Send 1908 USSD: Dial USSD String 
Communication (Choices and press at . . 7 to 
following 


for Preference{s)) prompt to text to unblock/ block unblock/ block 
unblock/ block 


Subscriber choosing the 
option of type of change it Opt-in /Opt-Out Opt-in /Opt-0 Opt-in /Opt-Out 
wants in its preferences. 
All Categories of Mode (to 
Nd: K K * * * 
he unblocked/blocked) U. —. BLOCK 10 | *1909*80#] *1909°10# 
lioice Call, UNBLOCK | BLOCK 11 | *1909*81#| *1909*11# 
81 
(isms, UNBLOCK | BLOCK 12 | *1909*°82#| *1909°12# 
82 
"auto Dialer Call (With 
Prerecorded UNBLOCK | BLOCK 13 | *1909*83#| *1909*13# 
Announcement), 83 
{iv i, 7 
auto Dialer Call (With UNBLOCK | BLOCK 14 | *1909*84#| *1909°14# 
Connectivity to live agent}, 34 
(Vv) Robo-Calls, UNBLOCK | BLOCK 15 | *1909*8S#/ *1909°15# 
85 


Table-2 shows the list of categories of mode of communication available as choices for 
preferences and the methods to unblock/block those categories of modes which includes — IVRS, 
SMS, USSD. Using any of the method provided, subscriber can unblock/block their preferences 
for mentioned categories of mode of communication for commercial communication. 





> On receiving the request in the form of call/message/USSD-string (as specified in 
Table 2) from the customer/subscriber, generate unique request number (URN) 
and process the request. 


> Subscriber should get notified by SMS comprising Unique Request Number 
(URN), timestamp of request, list of Mode of communication blocked for 
Commercial Communication, access provider name. 


> Update Distributed Ledger for Preferences (DL- Preference) within ‘X’ time. 


> After updating DL-Preference, communicate to subscriber with “Confirmation 
and Final Status along with options to block/unblock opted preference(s) of 
mode for commercial communication”. 


> In case of communication with customer executive of Customer Care Center, 
preference to opt-in/opt-out may be communicated. 


> Subscribes shall be communicated for the Lock-in Period of requested preference 
categories with effective timestamp. 


> BLOCK 10 option shall block all categories of modes except transactional type 
commercial communications while saving the status of customer for categories of 
time band and day types. 


> UNBLOCK 80 option shall restore all categories of modes for categories of time 
band and day types as per the previous status of customer when he exercised block 
option last time or as per the default options as the case maybe. 


> Incase, the Authority adds or removes number of categories, or sub-categories for 
mode, the solution is flexible and scalable and should be updated with the changes 
within X business days. 


» Procedure for registration or change of preference of Time band(s) for Commercial 
Communications 


Customer can opt-in/opt-out of any or all of following time bands for receiving of 
commercial communications. [To Unblock/Block] 


UCC Time band for 


Communication following text to 


{Choices for unblock/ block 
Preference(s)) 


Subscriber choosing the 
option of type of Opt-In /Opt-Out Opt-in /Opt-Out Opt-In /Opt-Out 
change it wants in its 
preferences. 
All Time Bands {to be UNBLOCK 
* 
' Ni 

(1}00:00 Hes to 06:00 Hrs, ° . BLOCK 21 | *15909*71#| 1909°11# 

(i)06:00 Hrs to 08:00 Hrs, 72 22 | UNBLOCK] BLOCK 22 | *1909°72#| *1909°22# 
72 

(i1)}08:00 Hrs to 10:00 Hrs,| 73 23 UNBLOCK} BLOCK 23 | *1909°73#| *1909°23# 
73 

(ivl40:00 Hes to 12:00 Hrs,| 74 24 UNBLOCK] BLOCK 24 | *1909°74#| *1909°24# 
74 

(v)12:00 Hes to 14:00 Hrs, 75 25 | UNBLOCK] BLOCK 25 | *1909°75#| *1909°25# 
75 

(vilt4:00 Hes to 16:00 Hrs,| 76 26 | UNBLOCK] BLOCK 26 | *1909°76#/ *1909°26# 
76 

(vii)16:00 Hes to 18:00Hrs,| 77 27 | UNBLOCK] BLOCK 27 | *1909°77#| *1909°27# 
77 

(vili48:00 Hrs to 21:00Hrs|} 78 28 | UNBLOCK] BLOCK 28 | °1909°78#| *1909°28# 
738 

(ix]21:00 Hrs to 24:00 Hrs, UNBLOCK] BLOCK 29 | *1909°75#| *1909°25# 
79 


Table-3 (Time Bands) 





Table 3 shows the list of Time-Bands for communication available as choices for preferences 
and the methods to block those categories of Time-Bands which includes — IVRS, SMS, USSD. 
Using any of the method provided, subscriber can unblock/block their preferences for mentioned 
Time-Bands for commercial communication 


Time Bands (i), (ii), (iii) and (ix) shall be default OFF/BLOCK for all 
customers irrespective of the status of registration of customer i.e. for all 
customers including those who have not registered any type of preference(s), 
anytime unless customer has registered its preference(s) and switched ON 


On receiving the request in the form of call/message/USSD-string (as specified in 
Table 3) from the customer/subscriber, generate unique request number (URN) 
and process the request. 


Subscriber should get notified by SMS comprising Unique Request Number 
(URN), timestamp of request, list of Time-Bands for communication 
unblocked/blocked for Commercial Communication, access provider name. 


Update Distributed Ledger for Preferences (DL- Preference) within ‘X’ time 


After updating DL-Preference, communicate to subscriber with “Confirmation 
and Final Status along with options to block/unblock opted preference(s) of 
time-bands for commercial communication”. 


In case of communication with customer executive of Customer Care Center, 
preference to opt-in/opt-out may be communicated. 


Subscribes shall be communicated for the Lock-in Period of requested preference 
categories with effective timestamp. 


BLOCK 20 option shall block all categories of modes while saving current status 
of customer for categories of content, time band and day types, however 
transactional type of commercial communications may not be blocked. 


UNBLOCK 70 shall restore all categories of time bands for the customer in which 
he was before he exercised option to block last time, if any, otherwise as per the 
default options. 


In case, the Authority adds or removes number of categories, or sub-categories for 
mode, the solution is flexible and scalable and should be updated with the changes 
within X business days. 


» Procedure for registration or change of preference of Day Type(s) for Commercial 
Communications 


Customer can opt-in/opt-out of any or all of following day types for commercial 
communication. [To Unblock/Block] 


Type(s) for 
ULE Day Tepety IVRS: Call to 1909 
receiving otal ias SMS: Send SMS to 1909 
Communication pean a following 
Choice for text 
( unblock/block 
Preference(s)) 


Subscriber choosing 

the option of type 

of change it wants Opt-in fOpt-Oat Opt-in /Opt-Out Opt-in /Opt-Out 

in its preferences. 
All Day Type(s) (to be unetock 60| BLocK 30 | *1909*60#| *1909*30# 
unblocked/blocked) 


(i) Monday oe UNBLOCK 61] BLOCK 31 | ey999*¢18  easorsue | 


ee 
fas [= [= feel wee fa 


(vill) Public Holiday and UNBLOCK 68| BLOCK38 | *1s05*6s#| *1509*384 
National Holiday 





Table 4 shows the list of Day-types for communication available as choices for preferences and 
the methods to block those categories of Time-Bands which includes — IVRS, SMS, USSD. 
Using any of the method provided, subscriber can unblock/block their preferences for mentioned 
Day-types for commercial communication. 


> On receiving the request in the form of call/message/USSD-string (as specified in 
Table 4) from the customer/subscriber, generate unique request number (URN) 
and process the request. 


> Subscriber should get notified by SMS comprising Unique Request Number 
(URN), timestamp of request, list of day-types opted for communication 
unblocked/blocked for Commercial Communication, access provider name. 


> Update Distributed Ledger for Preferences (DL- Preference) within ‘X’ time. 


> After updating DL-Preference, communicate to subscriber with “Confirmation 
and Final Status along with options to block/unblock opted preference(s) of 
time-bands for commercial communication”. 


> In case of communication with customer executive of Customer Care Center, 
preference to opt-in/opt-out may be communicated. 


> Subscribes shall be communicated for the Lock-in Period of requested preference 
categories with effective timestamp. 


> BLOCK 30 option shall block all categories of types of days while saving the status 
of customer for categories of time band and day types, however transactional type 
of commercial communications may not be blocked. 


> UNBLOCK 60 shall restore all categories of types of day for the customer in 
which he was before he exercised option to block last time, if any, otherwise as 
per the default options. 


> Incase, the Authority adds or removes number of categories, or sub-categories for 


mode, the solution is flexible and scalable and should be updated with the changes 
within X business days. 


»> Recording preferences on Distributed Ledger for Preferences (DL-Preferences) 


(1) Access Provider shall interact with DL-Preferences using Automated internal 
systems and appropriate APIs 


1. DL- preference is the distributed ledger that shall store the following 
preferences of subscribers — 


- Preference(s) of content categories of Commercial Communication. 
- Preference(s) of the mode(s) of communication, 
- Preference(s) of time band(s) and types of day(s) of the week 


2. Access mentioned functionalities using appropriate APIs. 


3. Internal Automated system shall process the request as soon as it received from 
the subscriber. 


4. The system has the following functionality — 


- Contains features of FETCH/READ, PUSH/WRITE. 
- A singleton format to WRITE/PUSH new record to the DL-Preference. 


(2) Record preferences on DL-Preferences within 5-10 minutes for requests received from 
all modes. 


(3) These revised preferences shall be available, in real time, for considerations by entities 
for scrubbing process for new list of telephone numbers under process, however, earlier 
messages or voice calls which have already been scrubbed and have validity may be 
delivered. 


»» Every Access Provider shall establish, maintain and operate Distributed Ledger(s) for 
Preference (DL-Preference) with requisite functions, process and interfaces 


(1) Record choices of preference(s) exercised by the customer in the Distribute Ledger for 
Preferences (DL-Preferences) in an immutable and non repudiable manner — 


(2) Record, at least, following details of the customer who has registered its preference(s): 


a) Telephone number in the international numbering format as referred in the 
National Numbering Plan. 

b) Location Routing Number (LRN), as assigned by DoT to the access provider, 
of current serving network of the customer and changes in LRN of the new 
serving network, in case customer is being ported-in during Mobile Number 
Portability 

c) Lifetime history, with date(s) and time stamp(s), of choices exercised by the 
customer for registering his preference(s) and subsequent changes to it made by 
the customer from time to time. 


d) Changes in the subscription of telephone number, during the process of 


opening and closing of subscription. 


e) Unique registration number issued at the time of registration of preference(s). 


(3) Interact and exchange information with other relevant entities, responsible to carry out 
functions for regulatory compliance(s), in a safe and secure manner. 


(4) Support any other functionalities as may be required to carry out functions for 
regulatory compliance(s): 


e Incase, the Authority adds or removes number of categories, or sub-categories for 
preferences, the solution is flexible and scalable and should be updated with the 
changes within X business days. 


»» Every Access Provider shall establish facility for revoking the consent by customers and 
make necessary arrangements 


(1) To receive request, from the customer, for revoking the consent, if any, given by the 
recipient to the sender or to the consent acquirer for the purpose of receiving a 
commercial communication message or voice call. 


(2) Provide modes, free of cost, to the customer, as per his choice, to revoke consent either 


by — 


(i) 


(ii) 


(iii) 


Sending SMS to short code 1909 with Label and or to telephone number 

mentioned in the message or during the voice call received from the 

sender(s) — 

1. Declare the template of SMS to revoke the consent. 

2. Register the template of SMS to revoke consent. 

3. Notify subscribers about the template to revoke consent in helpful 
manner. 


calling on 1909 or number mentioned for revoking the consent during the 

voice call received from the sender(s) — 

1. Provide free calling service on 1909 specified to revoke customers 
consent and accept the request for revocation of the consent. 

2. Use the interactive voice response system to accept request for the 
consent revocation. 


Calling on customer care number 

1. Use customer care facility to accept request for the consent revocation. 

2. Redirect the customers call to the customer representatives to 
understand and accept the consent revocation request. 

3. Once the customer has requested for the consent, customer 
representative shall record the request to the system. 


(iv) Interactive Voice Response System (IVRS) 
1. Use the Interactive Voice Response System to accept request for 
consent revocation. 
2. IVRS shall contain options to request for consent revocation, status of 
request, complaint section, and speak with customer representatives. 
3. The customer representatives should understand and accept the 
request from customers. 


(v) Mobile app developed in this regard either by the Authority or by any other 
person or entity and approved by the Authority 
1. There is a separate section for consent revocation request in the app 
menu. 
2. Ensure all features of the sections are properly working. 
3. Customers shall request to revoke consent, complaint, view status in 
the in app section. 


(vi) | Web portal with authentication through OTP — 
1. There is a separate section in web portal for the consent revocation 
process. 
2. Process to request for the consent revocation shall be kept easy and 
simple for understanding. 
3. Verify the customer using OTP. 


Also, as subscriber/customer requests to revoke the consent, once the request has 
been recorded, process that request in the below mentioned 


a. Generate Unique Request Number (URN) for the request and 
process the request. 

b. Customer shall be communicated with the URN, requested list 
of consent for revocation, timestamp of request. 

c. Update the Distributed Ledger for Consent (DL-Consent). 

d. After updating DL-Consent, communicate to subscriber with 
“Confirmation and Final Status along with options to 
unblock/block opted consent for commercial 
communication”. 

e. Subscribers shall be communicated for the Lock-in Period of 
requested consent with effective timestamp. 

f. Complete the processing of the request in ‘X’ time so that there 
should no pile of pending request. 


(vit) Any other means as may be notified by the Authority from time to time. 


(3) To remove the recipient's contact information (telephone number to which the message 
was sent) from the consent record(s) corresponding to the sender for all purposes 
requiring explicit consent except in case specific purpose(s) is indicated by the customer 
during revocation of consent from the consent register within | business day. 


a) Customers have to provide explicit consent to remove their mobile number/contact 
information from the consent record(s) corresponding to sender for all purposes. 

b) Access provider shall provide the facility to accept consent to remove the contact 
information from the consent records corresponding to the sender. 

c) Once the customer has provided consent to remove the contact information, it 
should be processed within 1 business day. 

d) Customer to be communicated with the status of the request, URN and timestamp 
of the request. 

e) After successful removal of the contact information, customer to be communicated 
with final status of the request. 


(4) To duly acknowledge the customer’s request to revoke the consent with unique 
reference number. 


Customers to be communicated with the URN, status of request, timestamp of the 
request, and title of consent revoked. 


(5) To ensure that any person who receives request to revoke consent must not disclose the 
customer's personal information to others without his consent. 


1. It is a responsibility to protect the personal information of the customer who 
requests for the consent revocation. 
2. Ensure that no person should disclose personal information. 


(6) To fetch details of the consent including its purpose(s), details about day and time when 
it was taken, and details about sender(s) or consent acquirer(s) who has or have taken 
the consent. 


Access provider shall make necessary arrangement to fetch details of— 
a. Consent ,including its purpose 
b. Timestamp of the consent acquired 
c. Details of Sender/consent acquirer who acquire the consent 


»» Every Access Provider shall establish, maintain and operate Distributed Ledger(s) for 
Consent (DL-Consent) with requisite functions, process and interfaces: - 


(1) To record consent given by the customer to sender(s) or consent acquirer(s) in the 
Distribute Ledger for Consent (DL-Consent) in an immutable and non repudiable 
manner. 


a) Only accept consent from a senders or consent acquirers in the template 
prescribed by consent registrar. 

b) Give clear instruction to the consent registrar to generate template for senders 
or consent acquirers to acquire consent from customers in such a way that — 


a. No fraud consent can be recorded by any senders or consent acquirers. 


(2) 


(3) 


Detailed process for acquiring consent from customers is specified 

c. OTP based verification of customers is done when sender asks for the 
consent. 

d. Template shall contain the Type and Purpose(s) of the consent, timestamp 
of consent taken, OTP verification status, Telephone Number, Header 
of senders or consent acquirers, Validity of consent. 


c) Once the consent acquirer(s) or sender(s) provide valid consent as per the template, 
access provider shall process the consent in following manner — 


a. Record the consent in the Distributed ledger for the Consent (DL-Consent). 
b. Recording of consent to the DL-Consent shall be processed in 5-10 min. 


To record, at least, following details of the consent: - 


Access provider shall only accept consent from a senders or consent acquirers in the 
template prescribed by consent registrar. 

Access Provider shall discard the consent records which does not have unfilled one 
or more than one fields in template. 


Template shall contain following field. 

1. Telephone number of customer in international numbering format as referred in 
National Numbering Plan. 

Header of Sender(s) or Consent Acquirer(s) against which consent is taken. 

Day & Time when consent was taken 

Validity period of consent 

Type and purpose(s) of consent. 


Ahn iad 


To make consent data accessible for other entities in safe and secure manner — 


Securing consent Data: Unscrupulous telemarketers and other intermediaries may 
deliberately leak preference data to unregistered telemarketers or data may also leak out 
because of inadequate measures taken by RTMs or intermediaries to protect or secure 
data. 

Therefore, mechanism used by the solution ensures that preference data or consent data 
used to scrub is protected. OTP based authentication for queries made by individuals 
may be introduced for protecting preference or consent data. 


1. Interact and exchange information with other relevant entities in safe and secure 
manner which includes - securing personal information of customers, 
contact information of customers, consent and preferences list, templates, 
Headers and content etc. 

2. The information is stored using permissioned blockchain in order to provide 
information security while exchanging information with other entities. 

3. No leak of any information in any form to unauthorized personal or 
organization or entity is entertained and handle such events immediately. 


(4) To keep record of revocation of consent by the customer with specific purpose(s), if 
any, in an immutable and non-repudiable manner; 


a. Functionality is provided to the customers to revoke their consent using one of 
the following method — 


I. 


Il. 


VI 


sending SMS to short code 1909 with Label and or to telephone number 
mentioned in the message or during the voice call received from the 
sender(s) 

calling on 1909 or number mentioned for revoking the consent during 
the voice call received from the sender(s) 

calling on customer care number 

Interactive Voice Response System (IVRS) 

Mobile app developed in this regard either by the Authority or by any 
other person or entity and approved by the Authority 

Web portal with authentication through OTP 


b. As customer requests to revoke the consent, request shall process in following 


manner — 
I. Generate Unique Request Number (URN) for the request and process 
the request. 
II. | Customer shall be communicated with the URN, requested list of 
consent for revocation, timestamp of request. 

Ill. Update the Distributed Ledger for Consent (DL-Consent). 

IV. After updating DL-Consent, communicate to subscriber with 
“Confirmation and Final Status along with options to block opted 
consent for commercial communication”. 

V. Subscribers shall be communicated for the Lock-in Period of requested 
consent with effective timestamp. 

VI. Complete the processing of the request in ‘X’ time so that there should 


no pile of pending request. 


(5) To interact and exchange information with other relevant entities, responsible to carry 
out functions for regulatory compliance(s), in a safe and secure manner — 


1. Cryptographic functionalities are implemented to secure data while information 
exchange process. 

2. Interact and exchange information with other relevant entities in safe and secure 
manner, this includes - securing personal information of customers, contact 
information of customers, consent and preferences list, templates, Headers and 
content etc. 

3. Store the information using permissioned blockchain in order to provide 
information security while exchanging information with other entities. 


(6) To support any other functionalities as may be required to carry out functions for 
regulatory compliance(s) — 


In case, the Authority adds or removes number of categories, or sub- 
categories or functionalities, the solution is flexible and scalable and should 
be updated with the changes within X business days. 


»>» Every Access Provider shall specify and classify clearly the following — 


A. Entity and process for generation of One Time Password (OTP) for different purposes 
and its validity period. 


1. 


Specify the list of participant entities in the process for generation of the OTP 
for different purposes and its validity period. 

Specify the process for generation of OTP and its validity period. 

Specified process shall be carried out in secure manner to provide security to 
personal information or contact information. 

Describe the different purposes of OTP in the process of Generating OTP and shall 
be communicated to the customer with OTP. 


B. Entity and process for verification of OTP received from the customer or for verification 
of entity carrying out activity under Code(s) of Practice for Entities. 


hs 


Specify the list of participant entities in the process for verification of the OTP 
received from the customers. 

Specify the process for verification of OTP received from customers. 

Specified process shall be carried out in secure manner to provide security to 
personal information or contact information. 

Access providers shall describe the different purposes of OTP in the process of 
verification of OTP and shall be communicated to the customer with OTP. 


» Formulate — 

A. Message Sequence Charts for messages with parameter details and time sequence to 
provide details about the process between two entities and action taken by particular 
entity. 

B. Flow Charts to provide details about the process between two entities and action taken. 


ASSUMED GUIDELINES : 3 


( COMPLAINTS ) 


**The Assumed Guidelines does not represent a guide to the new Unsolicited commercial 
communication Code nor does it replace or supplement its provisions by imposing any new rights or 
obligations on the respective parties. Instead it is designed to complement the new Code by suggesting 
best practice to facilitate positive and productive engagement between all parties across a range of issues, 
roles and responsibilities. Whilst the Code of Practice provides some examples of best practice these are 
not intended to be exhaustive. 


General 


7. Access Provider who adopt this Assumed Guidelines will state so on their respective websites. 


8. Access Provider who adopt this Assumed Guidelines may also state so on their contracts. 


9. Access Provider who adopt this Assumed Guidelines has to adopt a Code of Practice for all new 
contracts, and other specified contracts, that are entered into after an effective date to be 


announced by the individual service provider. 


Preamble 


“Access Provider” is committed to the best possible use of its expertise/experience in order to satisfy the 
customers. Exceeding their expectations will always be the first priority in planning and delivering 
telecom services. 


Company Mission 


“Access Provider” believes that prompt response/co-operation is the first step towards development of 
long-term and prospective business relationship. We are committed to Quality Services for dynamic 
growth of the company. 


“Access Provider” is fully committed in fulfilling its Corporate Mission which is that: 


“ “Access Provider’ shall enable the smooth process of acquiring or registering the complaints and solving 
these registered complaints of the customers, and always perceive its services and customer’s complaint 
handling to be of the highest quality. Our customers shall view us as a trusted and honest company that 
always delivers on its promises”. 


Purpose of laying down the Assumed Guidelines for Complaint Registration. 
The purpose of laying down the Assumed Guidelines for Complaint Registration is to: 


7. Bring uniformity and transparency in the procedures being followed by Access Providerwith 
regard to complaints registered by the users. 

8. Prescribe standards relating to acknowledgment of time and status of the complaints registered by 
the users. 

9. Measure the accuracy of solving the complaints within the provided time by the Access 
Providerfrom time to time and to compare them with the norms so as to assess the level of 
performance. 

10. Minimize the incidences of UCC complaints. 

11. Protect the interest of consumers of telecommunication services. 


Review 


The COP which the Access Provider will create for complaints as given in TRAI regulation may be 
reviewed by the Authority from time to time. The Authority, on reference from any affected party, and for 
good and sufficient reasons, may review and modify this regulation. 


List of Action items for Assumed Guidelines for Complaint Handling 


»> Customer Complaint Registration Facility (CCRF) shall be established and shall make necessary 
arrangements to facilitate customers on 24 hours X 7 days basis throughout the year: - 


(So CCRF must include a dedicated team of executives to solve the complaints and follow the rest of the 
procedure.) 


e To provide ways and means: - 


a. to make complaint(s), by its customer who has registered their preference(s), against sender(s) of 
unsolicited commercial communication in violation of the registered preferences or digitally 


registered consents; 


(Customer needs to submit their consent and set their preferences to register their complaints. Otherwise, 


the customers won’t be addressed regarding the complaints they have made.) 


b. to submit report(s), against sender(s) of commercial communication in violation of provisions of 
these regulation(s) by any customer; 


(Maintain records of complaints, from its customers and received from Terminating Access Provider 
against registered , un-registered senders and submit the report to Authority in respect of UCC which can 
be audited in future by the Authority) 


e to provide following modes, as per choice of the customer and free of cost, to make complaint or 
to report violation of regulations: - 


- sending SMS to short code 1909; or 
- calling on 1909; or 
-Interactive Voice Response System (IVRS); or 


-Mobile app developed in this regard either by the Authority or by any other person or entity and 
approved by the Authority; or 


-Web portal with authentication through One Time Password (OTP); or 
-Any other means as may be notified by the Authority from time to time. 


Provided that every such complaint shall be made by a subscriber within three days of receipt 
of the unsolicited commercial communication; 


It is hence mandatory 


e to duly acknowledge the receipt within fifteen minutes of the complaint or report made by the 
customer with unique reference number; 


e@ to provide details to the subscriber about the mobile app (stated above) to provide details about 
format and procedure to the customer, as given in the appropriate Code(s) of Practice, where a 
complaint is reyected by the access provider on the grounds of incomplete information or improper 
format; 


/* explanation of choices of sending the complaint*/ 
Registration of DND complaint by SMS to 1909 


A complaint template for registration of UCC shall be provided to the customer based on fixed text 
and the variable text so that the customer's query can be directed to the DL-Complaint with ease. 


Format - COMP TEL NO XXXXXXXXXX, dd/mm/yy, Time hh:mm 


Here the COMP TEL NO is the fixed format and XXXXXXXXXxX should be replaced by the 
telephone number or message header of the unsolicited call or message received by the customer. 


Examples of how the customer is supposed to register the complaint- 


Example 1): Customer has received an SMS from DM-IAMU on 30th Sep’11 at 2pm. Then his complaint 
SMS will be “COMP TEL NO DM-IAMU, 30/09/11, Time 14:00” and send it to 1909. 


Example 2): Customer has received an SMS / call from 9123456789 on Ist Oct?11 at 11.35am. Then his 
complaint SMS will be “COMP TEL NO 9123456789, 01/10/11, Time 11:35” and send it to 1909. 


Registration of DND complaint by Calling on 1909 


When the customer calls up on 1909 an IVRS provides the various options which are provided below 


1. Subscribe the new Preferences 

2. Unsubscribe the DND Services 

3. Know about DND Status 

4 Register for DND Complaint 
Here the customer will be choosing the 4th option and the IVRS will connect the call to the Access 
Provider's Customer Service Executive. 


The executive answering the call should note down the telephone number or message header of the 
unsolicited call or message , date and time of occurence and the explanation of the query by the customer 
and save the data in the DL-Complaints. 


Registration of DND complaint by Mobile App 


e Mobile App may be very helpful for the customer to intuitively and intelligently select the 
probable telephone numbers which may be UCC. 

e Mobile App also helps the customer to retrieve requisite information from the device to make 
complaint in a convenient manner. 

e It avoids or eliminates chances of rejection of complaint on grounds of non-availability of 


requisite details. 
e App can also pre-validate data and submit information to other systems in a structured form. 
This helps to automate the process and take quick actions. 


The application provides the various options and out of these options 4 are the main which are 
provided below- 


1. Report Voice UCC 

2. Report SMS UCC 

3 UCC Complaint 

4 Registration Status 
The customer can report complaints against the Voice Call and SMS UCC and can select the category 
the like 


a. Banking/Insurance/Financial Products/Credit Cards 
b. Real Estate 

c. Education 

d. Health 

e. Consumer goods and automobiles 

f. Communication/Broadcasting/Entertainment/IT 

g. Tourism 


and after selecting any one of these options the application will send the complaint request via SMS 
using the codes of category of specified content. 


Registration of DND complaint by Web Portal 


Web portal may also help in pre-validating data and submitting information in structured form. But in case 
of making complaints via web portal or using another phone number other than the phone number on which 
UCC was received, authentication may be required via OTP. 


Customer can login in the web portal by providing the registered Mobile Number and the OTP for 
login will be provided to the customer for validation. 


The Web Portal provides the various options regarding the DND Complaints and out of these options 
4 are the main which are provided below- 


1. 


2. 


3 


4. 


Report Voice UCC 
Report SMS UCC 
UCC Complaint 
Registration Status 


The customer can report complaints against the Voice Call and SMS UCC and can select the category 
the like 


a. Banking/Insurance/Financial Products/Credit Cards 
b. Real Estate 

c. Education 

d. Health 

e. Consumer goods and automobiles 

f. Communication/Broadcasting/Entertainment/IT 


g. Tourism 


and after selecting any one of these options the application will send the complaint request via SMS 
using the codes of category of specified content. 


Similar to the provisions in the current regulations, "access provider" should establish CCRF for its 
customers to make complaint(s). 


Facility may be made more efficient and effective by automating most of the complaint handling 
processes. 

Time required to register and acknowledge the complaint should be least considering 
computational resources and networking technologies which are available now-a-days. 

System shall quickly check whether requisite information is available or more information is to 
be sought from the complainant. 


If customer is not using the mobile app or web portal, it is required to guide him or her about the 
procedure for making complaint. This may be done by providing information via SMS, referring to links 
to get more information or suggesting available alternative modes to make complaints. 


In view of this, the Authority stated that complaint may be acknowledged by the each and every 
"access provider" within fifteen minutes by sending unique reference number to the complainant. 


Processes of CCRF may be automated and improved to make them more interactive in handling 
the registration of a complaint. 


» Distributed Ledger(s) for Complaints: 


Distributed Ledger Technologies (DLT) with complementing technology and platforms can record 
complaints in an immutable and non repudiable manner and can provide sharing of complaint related 
data, history of complainant, and history of person or entity against whom complaint is made easily 
accessible. Actions performed by participants in the UCC eco system while dealing with complaint 
resolution should be made transparent and auditable. 


"Access Provider" shall establish Distributed Ledger(s) for Complaints (DL-Complaints) with 
requisite functions, processes and interfaces to provide facilities for its customers to register 
complaints against Sender(s) of Commercial Communication and maintain complete and accurate 
records of status of resolution of complaints; 


e To examine and investigate complaints, take actions against defaulters and take remedial 
measures to ensure compliance with the regulations; 


e torecord complaints and reports regarding violation of Regulations made by the customer in the 
Distributed Ledger for Complaints (DL-Complaints) in an immutable and non repudiable manner; 

e to record, at least, following details about the complaint or report regarding violation of 
Regulations: 


- telephone number(s) or header(s) from which Unsolicited Commercial Communication was received; 


- telephone number(s) of Complainant or reporter; 


- Referred telephone number(s) (RTN), if any; 


- Date and time of occurrence of Unsolicited Commercial Communication, if available; unique 
registration number issued at the time of making complaint or reporting; 


-resolution status of the complaint or report regarding violation of Regulations; 


e torecord three years history of complainant with details of all complaint(s) made by him, with 
date(s) and time(s), and status of resolution of complaints; 


e torecord three years history of sender(s) against which complaint is made or reported with details 
of all complaint(s), with date(s) and time(s), and status of resolution of complaints; 


to interact and exchange information with other relevant entities in a safe and secure manner; 
to support any other functionalities as required to carry out functions. 


e To comply with any other directions, guidelines and instructions issued by the Authority 
in this regard. 


The above provided points are mandatory to the functionality of DL-Complaints and the records for the 
history of complaint and history of sender against whom UCC is registered which can be audited by the 
Authority without any acknowledgement to the “Access Provider”. 


>> Complaint Mechanism: 


Every Access Provider shall establish system(s), functions and processes to resolve 
complaints made by the customers and to take remedial action against sender(s) as 
provided hereunder: 


e "Terminating Access Provider (TAP)" shall record the complaint on DL-Complaints in non- 
repudiable and immutable manner and shall notify, in real time, the details of the complaint to the 
concerned Originating Access Provider (OAP). 


e "Terminating Access Provider (TAP)" shall examine within one business day from the date of 
receipt of complaint, to check the occurrence of complained communication between the 
complainant and the reported telephone number or header from which unsolicited commercial 
communication was received and update the findings on DL-Complaints. 


e Terminating Access Provider shall also verify if the date of receipt of complaint is within three 
days of receiving commercial communication and in case the complaint is reported by the 
customer after three days, the TAP shall communicate to the customer about the closure of his 


complaint in accordance to the Code of Practice for Complaint Handling and change status of 
complaint on DL-Complaint as a report instead of complaint. 


The OAP, in case the complaint is related to RTM, shall examine, within one business day from 
the date of receipt of complaint, whether all regulatory pre-checks were carried out in the reported 
case before delivering Unsolicited Commercial Communications; and 
© Incase, all regulatory pre-checks were carried out and delivery of commercial 
communication to the recipient was in confirmation to the provisions in the regulations 
and Code(s) of Practice,OAP shall communicate to TAP to inform complainant about the 
closure of complaint and forward the status to the customer. 


© incase of non-compliance with the regulations, the OAP shall, within two business days 
from the date of receipt of complaint, take actions against the defaulting entity and 
communicate to TAP to inform the complainant about the action taken against his 
complaint as provided for in Code(s) of Practice; the OAP shall take appropriate 
remedial action, as provided for in the Code of Practice(s), to control Unsolicted 
Commercial Communications so as to ensure compliance with these regulations; 


The OAP, in case, the complaint is related to a UTM, shall examine communication detail 
records (CDRs), within one business day from the date of receipt of complaint, to check the 
occurrence of complained communication between the complainant and the reported telephone 
number or header from which unsolicited commercial communication was received. 


© Incase of no occurrence of complained communications, OAP shall communicate to the 
TAP to inform the complainant about the closure of complaint in a manner prescribed in the 
Code(s) of Practice; 


© Incase of occurrence of complained communications, OAP shall further examine, within 
two business days from the date of complaint, whether there are similar complaints or 
reports against the same sender; and 
«incase, it is found that number of complaints against the sender are from ten or 
more than ten recipients over a period of last seven days, the OAP shall put sender 
under Usage Cap and at the same time shall initiate investigation . 


Provided that such Usage Cap shall be valid till investigation is completed or thirty days from 
the date of effect of restrictions, whichever is earlier; 


* incase it is found that number of complaints against the sender are from less than 
ten recipients over a period of last seven days, the OAP shall, from the previous 
thirty days data of CoP_UCC_Detect System, check whether suspected sender is 
involved in sending Commercial Communication in bulk or not; and 

@ incase, sender has sent commercial communications in bulk, the OAP shall 
put the sender under Usage Cap, and at the same time initiate investigation 


> 


Provided that such restrictions shall be valid till investigation in this regard is completed under 
relevant regulations or thirty days from the date of effect of restrictions, whichever is earlier; 


@ incase, sender has not sent commercial communications in bulk, the OAP 
shall warn such sender through appropriate means; 


e OAP shall issue notice, within three business days, to give opportunity to such sender(s), to represent 
his case and shall investigate, within thirty business days from the date of receipt of complaint and 
shall conclude whether the communication so made was unsolicited commercial communication or 
not; and conclusion of the investigation was that sender was engaged in sending unsolicited 
commercial communications, OAP shall take action against such sender as under: - 

© for first instance of violation, due warning shall be given; 


Provided that the first instance of the violation shall include all the complaints against the sender 
within two business days after the date of receipt of the first complaint, against which the sender 
is to be warned. 


e for the second instance of violation, Usage Cap shall continue for a period of six 
months; 


Provided that the second instance of the violation shall include all the complaints against the 
sender after the issuance of first warning within two business days after the date of receipt of the 
complaint against which second warning is being given to the sender. 


e for third and subsequent instances of violations, all telecom resources of the sender 
shall be disconnected for a period up to two years and OAP shall put the sender under 
blacklist category and communicate to all other access providers to not to allocate 
new telecom resources to such sender for up to two years from the date of such 
communication; 


Provided that the third instance of the violation shall include all the complaints received against 
the sender after the date of second warning within two business days after the receipt of the 
complaint against which telecom resources are being disconnected. 


Provided further that one telephone number may be allowed to be retained by such sender with the Usage 
Cap for a period up to two years. 


>> Record keeping and reporting: 


"Access Provider" shall maintain records of complaints, from its customers and received from 
Terminating Access Provider(s), against registered sender(s) for sending unsolicited commercial 
communications on daily basis for each service area and submit performance monitoring report to 
the Authority as and when required in a format as prescribed. 


e Every Access Provider shall maintain records of complaints, from its customers and received 
from Terminating Access Provider(s), against unregistered sender(s) for sending unsolicited 
commercial communications on daily basis for each service area and submit performance 
monitoring report to the Authority as and when required in a format as prescribed. 


e Every Access Provider shall submit to the Authority its compliance reports in respect of 
unsolicited commercial communications, complaints or reports from its customers in such manner 
and format, at such periodic intervals and within such time limits as may be specified by the 
Authority, from time to time, by an order or direction; 


e The Authority may, from time to time, through audit conducted either by its own officers or 
employees or through agency appointed by it, verify and assess the process followed by the 
access provider for registration and resolution of complaints, examination and investigation of the 
complaints and reporting to the Authority. 


>» Consequences for the Originating Access Provider (OAP) failing to curb the unsolicited 
commercial communications sent through its network(s): - 


e If OAP fails to curb UCC, Financial Disincentives for not controlling the Unsolicited Commercial 
Communications (UCC) from RTMs by the access provider in each License Service Area for one 
calendar month shall be as under: - 


Value of “Counts of UCC for RTMs for one calendar month” Amount of financial 
disincentives in 
Rupees 


More than zero but not exceeding hundred Rupees one thousand 
per count 


More than hundred but not exceeding one thousand Maximum financial 
disincentives at (a) 
plus Rupees five 
thousand per count 
exceeding hundred 


More than one thousand Maximum financial 
disincentives at (b) 
plus Rupees ten 
thousand per count 
exceeding one 
thousand 





Provided that no order for payment of any amount by way of financial disincentive shall be made by the 
Authority, unless the concerned Access Provider has been given a reasonable opportunity to represent. 


The amount payable by way of financial disincentive under these regulations shall be remitted to such 
head of account as may be specified by the Authority. 


e The total amount payable as financial disincentives shall not exceed rupees fifty lakhs per 
calendar month. The Authority may impose no financial disincentive or a lower amount of 
financial disincentive than the amount payable where it finds merit in the reasons furnished by the 
access provider. 


»» Consequences for contravention of the provisions of regulations by Access Providers: - 


e Power of Authority to order inquiry: - 

« Where the Authority has a reason to believe that any Access Provider has 
contravened the provisions of these regulations, it may constitute an inquiry 
committee, to inquire into the contravention of the regulations and to report 
thereon to the Authority. 

« The inquiry committee shall give a reasonable opportunity to the concerned 
Access Provider to represent itself, before submitting its findings to the Authority. 


o If on inquiry, the Access Provider is found to have misreported the count of UCC for 
RTMs, it shall, without prejudice to any penalty which may be imposed under its licence 
or other provisions under these regulations, be liable to pay, by way of financial 
disincentive, an amount 

o ten times the difference between disincentive computed by the Inquiry Committee 
and that computed earlier based on service provider’s data, or Rs 5 lakhs, 
whichever is higher; and 


Provided that in case of second and subsequent contraventions, to pay an amount equal to 
twice that of computed financial disincentives 


o one lakh per instance for access provider found to be not imposing timely 
restrictions on outgoing usage of unregistered sender(s) . 


Provided that no order for payment of any amount by way of financial disincentive shall be 
made by the Authority, unless the concerned Access Provider had been given a reasonable 
opportunity of representing against the findings of the inquiry committee. 


The amount payable by way of financial disincentive under these regulations shall be remitted to such 
head of account as may be specified by the Authority. 


The total amount payable as financial shall not exceed rupees ten lakhs in a week. 


e The Authority may impose no financial disincentive or a lower amount of financial 
disincentive than the amount payable where it finds merit in the reasons furnished by the 
access provider. 


» Examination of telecom resources put under outgoing Usage Cap or having been 
disconnected: - 


e The Authority may, if it considers expedient to do so, on receipt of complaint, call for the 
details of the telecom resources put under Usage Cap or disconnected, on account of 
unregistered telemarketing activity under and upon examination, for reasons to be 
recorded, 


o If the Authority finds that conclusion of investigation lacks adequate evidence 
against the sender, it may direct the Access Provider to remove such restrictions 
on usage or restore all telephone number(s) of the person and delete the name and 
address of such customer(s) or sender(s) from the blacklist. 


o If the customer or the Sender whose telecom resources have been put under 
restriction or disconnected on account of adequate evidence against the sender, 
makes a request, within sixty days of such action, to the Authority for restoring 
his telecom resources or removing the restrictions on usage and satisfies the 
Authority that it has taken reasonable steps to prevent recurrence of such 
contravention, the Authority may by order ask access provider(s) to remove such 
restrictions on usage or restore all telephone number(s) of the person and delete 
the name and address of such Sender(s) from the blacklist, as the case may be, on 
payment of an amount of five thousand rupees per resource to the Authority for 
restoration of all such telecom resources, subject to the condition that the total 
amount payable by the customer or sender shall not exceed rupees five lakhs. 


Provided that the Authority may impose no financial disincentive or impose a lower amount where it finds 
merit in the reasons furnished by the customer. 


For controlling UCC from unregistered telemarketers, all customers using telecom networks may be 
advised not to indulge in UTM activities, otherwise they may be put under Usage Cap or their telecom 
resources disconnected. Similarly, there is need to have provisions that principal entities (or business 
entities) do not indulge in UTM activity, directly or indirectly. Further, they may be made aware of these 
provisions by the access providers. System and processes are required that encourage entities to get 
registered and on-boarded to UCC eco system before making commercial communications. Measures 
specified in Para 3 and Para 4 are already part of such UCC eco system to better match the interests of 
sender and recipients, to protect the interests of business entities, and to permit the options for reaching 
out customers when there are legitimate and justified reasons. 


Entertaining complaints from customers not registered on DL-Preferences: The present system does 
not have provision of lodging complaint by the customer who have not registered any preference(s). 


e However, there are certain instances of violation of provisions of regulation like UCC from 
UTM, UCC beyond permissible hours etc., where unregistered subscriber may also like to 
register complaints. Such complaints may be treated differently compared to normal 
complaints by a customer registered on DLPreferences. These may be referred as “reports” 
instead of “complaints”. 


e Complaints received after the specified time period from a customer registered on DL- 
Preferences or those with insufficient evidence may also be recorded as reports. Taking 
such complaints into account would help identify UTMs or RTMs who indulge in activities 
are not permitted under the regulations. When suspected UTM is sending UCC in bulk then 
only complaints which may be few in numbers may be relied upon. It would require 
defining meaning of bulk. 


e Similar approach has been adopted in other jurisdictions such as in Singapore where in 
bulk is defined in the Spam Control Act (SCA) 2007, for details refer link 
https://sso.agc.gov.sg/Act/SCA2007. 





In view of this, the Authority also decides to define bulk based on number of messages or voice 
calls made during 24 hours, seven days and thirty days. The Authority also decides that Access 
Provider should entertain reports from such customers for detection of bulk UCC sender and 
non-compliance of regulation. Access Provider may be required to consider all the complaints 
made within relevant time period of commercial communication. Even if the complaint is 
received after the specified time period, TSP should not reject it, but consider it as report for use 
in UCC detection. 


Preliminary Examination of Complaints by OAP: To deal with complaints related to RTM, both the 
TAP and OAP have to investigate and resolve the complaint in parallel. Action against the RTMs must be 
part of Code of Practice for Complaint handling. UCC eco system is to be controlled and managed by the 
access provider and specific actions to be taken against RTMs would be part of CoPs. Access provider’s 
performance in terms of keeping a check on RTMs would be measured on the basis of aggregated 
complaints received by OAP against RTMs. OAP should carry preliminary examination of the complaints 
in two days so that appropriate action may be taken against suspected sender of UCC. 


In view of above, For OAP, the Authority decides that in case the complaint is related to RTM, OAP 
should examine, within one business day from the date of receipt of complaint, whether all 
regulatory pre-checks were carried out in the reported case before delivering UCC, and in case, 
answer is yes then OAP should communicate to TAP to inform complainant about the closure of 
complaint as provided for in the Code(s) of Practice. In case, answer is no, then OAP should, within 
two business days from the date of receipt of complaint, take actions against the defaulting entity 
and communicate to TAP to inform the complainant about the action taken against his complaint 
as provided for in Code(s) of Practice. 


> Structured way to deal with complaints against suspected UTMs: 


The Distributed Ledger for Complaints (DL-Complaints) having histories of complainant and against 
whom complaints are being made used in conjunction with UCC_Detect_System would make it possible 
to precisely identify UTMs. 


This approach would minimize victimization, while effectively detecting UTMs and prevent them from 
sending UCC. 


In view of above, the Authority decides that in case of complaint against a UTM also the OAP should 
examine CDRs in parallel to TAP, within one business day from the date of receipt of complaint, to 
check the occurrence of communication that is under investigation. In case, answer is no, then OAP 
should communicate to the TAP to inform the complainant about the closure of complaint in a 
manner prescribed in the CoP. In case answer is yes, then OAP should further examine, within two 
business days, whether there are similar complaints or reports against the same sender. 


i. Action should be expedited to control UCC, if multiple complaints are received against same sender, 
Usage Cap should be applied immediately, which may be restored after due investigation if there is no 
guilt. Sufficient time should be given for concluding the investigation as opportunity must be given to the 
sender who is kept under Usage Cap to defend themselves. 


The Authority decides that if there are complaints against the sender from ten or more recipients 
over a period of seven days preceding the date of receiving complaint, the OAP should put the 
sender under Usage Cap and at the same time should initiate investigation. Such restrictions should 
be in place till investigation is complete or for thirty days from the date of effect of restrictions, 
whichever is earlier. 


ii. If complaints are not received from multiple recipients then before taking action, more checks should be 
done to find out whether sender has sent only few messages or made only few calls and can not reasonably 
be considered as UTM. In view of this the Authority decides that where number of complaints are 
from less than ten recipients, the OAP should, check from the previous thirty days data of 
CoP_UCC_Detect System whether suspected sender is involved in sending Commercial 
Communication in bulk or not (Definition of bulk may be by counting communications over a period of 
24 hours, over a week and over a month). 


a. in case, answer is yes, the OAP should put sender under Usage Cap and at the same 
time initiate investigation. 


Such restrictions should be valid till investigation or thirty days from the date of effect of 
restrictions, whichever is earlier. 


b. in case, answer is no, OAP should warn such sender through appropriate means as 
provided for in CoPs and remove the usage cap. 


iii. Sender should be given opportunity to represent his case before finally concluding the investigation. If 
sender was found indulging in UCC in violation of regulations, he should be given warning for the first 
offence and the Usage Cap removed. If the violation is repeated a second time, Usage Cap should be 
applied for longer period and in case of third time, all resources should be disconnected except one which 
may be provided with Usage Cap to use minimum functional requirements for daily use. In view of this 
the Authority decides that OAP should issue notice, within three business days, to give opportunity 
to suspected sender(s) to represent his case and conclude investigation within thirty business days 
from the date of receipt of complaint and if sender is found to be indulging in sending UCC then 
OAP should take action against such sender as under: - 


a. for first instance of violation, due warning shall be given. First instance of the 
violation should include all the complaints against the sender within two business days 
after the date of receipt of the first complaint, against which the sender is to be warned. 


b. for second instance of violation, Usage Cap should continue for a period of six 
months. Second instance of the violation should include all the complaints against the 
sender after the issuance of first warning within two business days after the date of receipt 
of the complaint against which second warning is being given to the sender. 


c. for third and subsequent instances of violations, all telecom resources of the sender 
shall be disconnected for a period up to two years. 


Review of structure of financial disincentive for access providers: At present, access providers are 
subject to financial disincentive if UCC complaints are found to have originated from their network. 


Financial disincentive for UCC complaint are being imposed on weekly basis and the provision of 
financial disincentive is applied even when UCC complaints are handled within given time frame and 
expected action is taken against UTM or RTM. At the time of amendment of the regulation for this 
provision, it was felt that Access Providers are responsible for carrying out due checks and verification of 
the customers and if bulk connections are being taken by customers and being misused then Access 
Providers are not discharging their due responsibilities. TSPs have represented, from time to time, against 
applying financial disincentives on counts of UCC complaints including even those UCC complaints on 
which they have taken timely action. 


i. In new regulatory framework where co-regulation approach is being adopted and COPs 
are to be formulated by the access providers, primary responsibility to control UCC is of 
access provider. OAPs failing to curb the UCC sent through its network(s) should be 
liable to pay by way of Financial Disincentives. The FDs should be telescopic; i.e. 
nominal if the number of incidences reported are below a threshold, but substantially 
higher if the number of cases beyond a certain threshold. In new regulatory framework, 
technology driven systems are to be put in place and access providers are given flexibility 
to act fast against the defaulter entities. It may also be noted that access providers are also 
given freedom to prescribe charges/ fees and access providers can also impose financial 
disincentives on defaulting entities for faults attributable to them. In such situation graded 
financial disincentives should be applied and it should increase substantially in case 
number of complaint rises against RTMs. 


In view of this, the Authority decides that FD for access provider, in case of complaints related 
RTMs should be based on the Count of UCC for RTMs for one calendar month in each License 
Service Area. It should be increased to Rs. One thousand per count if it is more than zero but not 
exceeding hundred. This should be increased to Rs. one lakh plus Rs. five thousand per count 
exceeding hundred when count is between one hundred and one thousand. This should be further 
increased to Rs. forty-six lakhs plus Rs. Ten thousand per count exceeding one thousand when total 
count is more than one thousand. 


ii. | Access providers are supposed to take action against UTMs suspected of sending UCC 
and also carry out due investigation and take appropriate action against the UTMs. 
Normally it is expected that access providers would be following processes and not to be 
held responsible for UCC from UTMs. Access provider would also be required to inform 
their subscribers to not send Commercial Communication or cause sending Commercial 
communication or authorize the sending of the Commercial Communication using the 
telecom resources failing which the telecom resources used or assigned to him may be put 
under Usage Cap or disconnected. 


iii. Access providers would have to establish UCC_Detect system to control UCC from UTMs. 
If access providers do not act against the detected UTMs in a timely manner, then they may 
be held accountable for not controlling UCC. If it comes to notice or is found during audit 
of the system that the access provider has not taken action against UTMs as specified in the 
regulations or CoPs then access provider may be liable to pay by way of financial 
disincentives. The FD in case of UTM may be dependent on every such instance. 

In view of this the Authority decides that Financial Disincentive of one lakh per instance of access 
provider failing to impose timely restrictions on outgoing usage of unregistered sender(s) be imposed 
on the access provider. 

iv. In view of UCC eco system based on DLT is created by the access provider(s) and measures 
taken to control the outgoing usage of telecom resources of suspected sender of UCC 
whenever it comes into notice, current provisions of Financial Disincentives for access 
providers may need to be revised. Access providers are supposed to apply Usage Cap within 
timelines prescribed in the regulations. If it comes to notice of the Authority that access 
provider is not taking such measures in timely manner and same is established through 
special audits and no satisfactory justifications for any delay in applying such measures, 
then access providers may be liable to pay by way of financial disincentives. 


Further specific details should be part of Codes of Practice for Complaint Handling (CoP-Complaints) and 
Code of Practice for UCC_Detect_System which should be formulated by the access providers. In view 
of this the Authority decides that access providers shall also formulate codes of practice for 
complaints (CoP-Complaints) and codes of practice for UCC Detect system (CoPUCC_Detect). 


»» Access providers may also be liable to pay by way of financial disincentives in case they do 
not establish eco system in accordance with the codes of practice. Such disincentives may be 
applicable till such system comes into existence and made live to deal with relevant aspects. 
However, after implementing such systems in accordance with the CoP, if non-compliance 
occurs due to some flaw in implementation or inappropriate configurations of the system then 
financial disincentives may be applicable in accordance to the provisions under count of UCC 
complaints and not against non-implementation of CoP. For example, if access provider has 
not implemented systems and process as defined in the codes of practice and UCC complaints 
are on rise due to non-implementation of CoP then financial disincentives may be applied for 
non-compliance of CoP. If access provider has implemented the system and subsequently 
UCC complaints are rising because of some issues related to system, then financial 
disincentives for non-implementation of CoP would not be applicable. Financial disincentives 
as applicable for UCC counts may be levied. However, if there is major non-compliance of 
CoP on part of system or there are multiple minor non-compliances in the system which 
amount to as complete failure of the system then financial disincentives for non-compliance 
of CoP may be applicable. 


>>» Every Access Provider shall formulate: - 


o Message Sequence Charts for messages with parameter details and time sequence to provide 
details about the process between two entities and action taken by particular entity; 


o Flow Charts to provide details about the process between two entities and action taken; 


ASSUMED GUIDELINES : 4 
( UCC-DETECTION ) 


**The Assumed Guidelines does not represent a guide to the new Unsolicited commercial 
communication Code nor does it replace or supplement its provisions by imposing any new 
rights or obligations on the respective parties. Instead it is designed to complement the new Code 
by suggesting best practice to facilitate positive and productive engagement between all parties 
across a range of issues, roles and responsibilities. Whilst the Code of Practice provides some 
examples of best practice these are not intended to be exhaustive. 


General 


10. Access Provider who adopt this Assumed Guidelines will state so on their respective 
websites. 


11. Access Provider who adopt this Assumed Guidelines may also state so on their contracts. 


12. Access Provider who adopt this Assumed Guidelines has to adopt a Code of Practice for 
all new contracts, and other specified contracts, that are entered into after an effective date 
to be announced by the individual service provider. 


Preamble 


“Access Provider” is committed to the best possible use of its expertise/experience in order to 
satisfy the customers. Exceeding their expectations will always be the first priority in planning 
and delivering telecom services. 


Company Mission 


“Access Provider” believes that prompt response/co-operation is the first step towards 
development of long-term and prospective business relationship. We are committed to Quality 
Services for dynamic growth of the company. 


“Access Provider” is fully committed in fulfilling its Corporate Mission which is that: 


“ “Access Provider’ shall enable the smooth process of acquiring or registering the complaints 
and solving these registered complaints of the customers, and always perceive its services and 
customer’s complaint handling to be of the highest quality. Our customers shall view us as a 
trusted and honest company that always delivers on its promises”. 


Purpose of laying down the Assumed Guidelines for Ucc Detection. 
The purpose of laying down the Assumed Guidelines for Ucc Detection is to: 


12. Bring uniformity and transparency in the procedures being followed by Access Provider 
with regard to Ucc Detection. 

13. Measure the accuracy of solving the complaints within the provided time by the Access 
Provider from time to time and to compare them with the norms so as to assess the level 
of performance. 

14. Minimize the incidences of UCC complaints. 

15. Protect the interest of consumers of telecommunication services. 


Review 


The COP which the Access Provider will create for complaints as given in TRAI regulation may 
be reviewed by the Authority from time to time. The Authority, on reference from any affected 
party, and for good and sufficient reasons, may review and modify this regulation. 


List of Action items for Code of Practice for Complaint Detection and Resolution 


»» Every Access Provider shall establish, maintain and operate following system, functions 
and processes to detect sender(s) who are sending Unsolicited Commercial 
Communications in bulk and not complying with the regulation(s), and act to curb such 
activities: - 


1) Systems which have intelligence at least following functionalities to be implemented 


a) Identifying sender on basis of the signature 

Identification of sender can be done by matching the Sender ID with Registration ID from 
DL-content. Upon matching the Sender ID with Registration ID, its corresponding content 
ID is fetched. 


b) Deploying honeypot(s) and using information collected by it 


e A telephony honeypot is a telephone service endpoint to which calls can be 
directed. It may appear to callers to be a normal telephone number (e.g., a typical 
10-digit residential or business phone number), but is specifically designed and 
deployed to collect information on unwanted calls. It might automatically process 
calls or employ humans, is computer monitored and might be recorded. 


e Data collected from honeypot(s) would ideally be used not only by the honeypot 
operator but also by other organizations. 


Data sharing between honeypot operators, service providers, and enforcement 
organizations allows for a more comprehensive view of abuse, and the fusion of 
data from multiple sources facilitates more effective mitigation. 


** Steps to be considered while deploying honeypot(s) 


1. Read as much as you can about honeypot(s) to get a thorough understanding of the task 
ahead. Know basic honeypot theory, especially the concepts of data control and data 
capture. 


2. Confirm that honeypot(s) are allowed in your environment. If you are setting up a 
honeypot as an employee, make sure to get the appropriate approvals. Adding a 
honeypot to your environment incurs additional risks—both technical and legal—that 
the organization may not want to support. 


3. Define the goals of your honeypot. Why do you want to run a honeypot? Is it for 
research or to protect your production environment? 


4. Define the human roles in creating and maintaining a honeypot. Do you have the 
technical expertise to correctly deploy and maintain a honeypot? Do you have the 
software and hardware necessary to deploy a honeypot? Do you have the extra hours in 
your workday that it will take to appropriately maintain the honeypot and do data 
analysis? Discuss the continuing education needed to keep up with the honeypot and 
new exploits. 


5. Figure out what type of honeypot you will deploy: research or production, real or 
virtual. 


6. Define, install, and configure the physical network devices needed to create your 
honeypot. 


7. Plan and configure the other supporting honeypot components and tools (alerting, 
logging, monitoring, management, and so on). 


8. Collect your own set of monitoring, logging, and forensic analysis tools. 


9. Develop a recovery plan. How are you going to restore the honeypot system back to an 
unaltered state after the current exploit event is finished? 


10. Deploy the honeypot and its supporting components. 


11. Test the deployment. Use vulnerability assessment and penetration testing tools against 
your honeypot system to see how well the system works. 


12. Analyze the results and eliminate any deficiencies. 
13. Fine-tune the honeypot system based on lessons learned. 


14. Repeat steps as necessary. 


Store collected data remotely. You can store as much evidence as you can remotely. If it is stored 
locally, the hacker can find it and erase it. 


c) Evolving signature(s) by learning over time 


e Enhanced signature solutions are for identifying unregistered telemarketing activity. 
Enhancements of signature solutions include sharing of information among access 
providers for continuous evolution of signatures, rules, and criteria and then 
applying machine learning on it. 


e There would be a separate database for storing identified unregistered Telemarketer 
which would be shared among all the access providers and only TRAI would have 


the access to this database. This shared database is used for training purposes so that 
it can predict the potential scammers. 


“* For the evolving of the signature over time, machine learning is being used. 
Two approaches are used: 
¢ Supervised machine learning 
¢ Unsupervised machine learning 
- Supervised machine learning 
These data sets can be used in supervised machine learning: 


i. User Profile 
uu. Geolocation 


lil. Contacts 


1. User Profile will have the following parameters : 


e Input/Output Ratio means a number of calls called/a number of calls received, 
higher the ratio, higher is the rating. 


e Number of SIM’s issued on a Unique ID (Aadhar Card) - If on a single ID, number 
of SIM’s are more than a threshold value XX then its rating will be according to 
the calculated threshold value 


e Age of the SIM - If the age of the SIM is more then it's likely that it is being used 
for personal use. If it's new then it can affect the overall rating. 


e Call timings - This can be divided into two parts: 


o During office hours( on average 9:00 to 17:30 ) 
o After office hours 


Most of the automated calls happen during office hours, thus contributing more 
towards the overall ratings. 


e Duration of call - Most of the automated calls that are of fellow seconds. We can 
calculate the deviation of call duration from the set threshold value XX. If the 
standard deviation is more than a set limit then effect on the overall rating is more. 


e Hop count means for how many hops it will search for the contact, for eg: If hop 
count is | then it will only search in its mutual contacts. 


2. Geolocation is having the following parameters : 


e Location 

e Calls in 

e Calls out 
If the call is from the location where dialed automated calls is high, then higher is 
its rating and vice versa. 


3. Contacts: Contacts will have the record of the contacts that are present in the user profile. 


If the received number is in the contacts then it’s unlikely that it will be a spam call. There 
is a threshold value XX up to which system will search for the received number in contacts 
of the contacts (up to threshold value). If the received number is not found, then it’s likely 
to be spam thus its rating is high. 


Different Parameters/Datasets can be added in future. User Profile is used for calculating the rating 
which further can be used for predicting for the scammer. 


Source of a collection of data for the datasets. 
User Profile — Data is collected from the profile of the user. 


e Input/Output Ratio — Telecom provider will provide user call logs, then we will 
calculate a number of calls dialed and a number of calls received and calculates 
their ratio. 


e A number of SIM's issued on a Unique [D(Aadhar Card) — Provided by the 
Telecom Providers. 


e Age of the SIM - Provided by the Telecom Provider. 

e Call timings - Provided by the Telecom Provider 

e Duration of call - Provided by the Telecom Provider 

e Geolocation — Data is collected via the deployed honeypot. 


e Contacts — User will give consent for reading the contacts. 


Affect of parameters on the current system .All the parameters will affect the overall rating of the 
user. 


d) Interface to exchange information with a similar system(s) established by other 
access providers (s) to evolve signature(s), detecting sender using Sender 
Information (SI); 


Different patterns can be used for exchanging information between the interfaces: 


There are three most commonly used patterns: 


1) Query/Response pattern 


Service 
Consumer 





The query/response pattern is the most common type of information exchange 
transaction. A sharing partner (service consumer) initiates a request, and a second 
partner (service provider) may respond to that request with either the requested 
information or call to a specific resource to obtain the information. 


A) Query 
Response > 


Service 


Provider 


Interface 
Interface 





2) Broadcast Pattern 


A broadcast exchange pattern can be an independent alert, warning, or notification 
exchange pattern that is disseminated to a varied set of mission partners across 
multiple mission areas to communicate details of a specific incident or event(s), and 
even solicit real-time operational assistance with a specific event or case related 
actions. 


Exchange patterns for broadcast messages will include similar elements as 
documented in the query/response pattern. However, these elements will be further 
elaborated to define implementation options, including architecture context and 
associated messaging depending on the type of broadcast. 


These options would include (along with architectural impact) situations where a 
service provider broadcasts messages to specific service consumers in a point-to- 
point messaging pattern, or in a publish-and-subscribe construct where the service 
provider publishes the broadcast message to a subscription service. These 
subscription services manage downstream technical requirements capabilities like 
mediation and transformation services, content-based routing, etc. In most cases, 
there is a system-level acknowledgment that confirms that the message was 
delivered successfully, with no real mission-specific responses expected as part of 
this pattern. 
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3) Workflow Pattern 


e Workflow pattern exchanges are typically part of an organization’s operational 
environment where information is routinely moved across mission partners to 
accomplish day-to-day operational requirements. 


e Anexample of such an exchange would be a police department sharing complaint 
information with a court’s case management system. This exchange initiates the 
creation of a case on the court’s docket and improves operational efficiencies by 
minimizing redundant data entry and associated data re-entry errors. 
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e) Considering inputs available from DL-Complaints about complaints and reports 
and analyze them 


1. Develop a plan before you analyze data. 


a. Specify how good is good enough. 


b. Specify what you will do with each kind of data, including when you will 
combine categories and how you will present results (as numbers, %s or 
categories). 


c. Figure out how you will handle missing data. 


2. Develop some dummy tables or lists to hold your analyzed data — share those with 
others. 


3. Identify the most important findings from your data, summarize them and then use the 


specific results (e.g., a table or list of data) to clarify your findings. 


4. Present your analysis in an orderly, meaningful, simple way. 


f) Considering inputs available, if any, from any other network element(s) of the access 
provider system(s); 


Access provider can acquire a significant amount of inputs from other access provider 
systems. 


Network elements of any other access provider can be the following: 


1. 


Input and output devices also referred to as 'terminals' 


These provide the starting and stopping points of all communication. A telephone 
is an example of a terminal. In computer networks, these devices are commonly 
referred to as 'nodes' and consist of computer and peripheral devices. 


Telecommunication channels, which transmit and receive data 


This includes various types of cables and wireless radio frequencies. 


Telecommunication processors, which provide a number of control and support 
functions 


For example, in many systems, data needs to be converted from analog to digital 
and back. 


Control software, which is responsible for controlling the functionality and 
activities of the network 


Messages represent the actual data that is being transmitted 


In the case of a telephone network, the messages would consist of audio as well as 
data. 


Protocols specify how each type of telecommunication systems handle the messages 


For example, GSM and 3G are protocols for mobile phone communications, and 
TCP/IP is a protocol for communications over the Internet. 


2) Provide ways and means for resolving complaint(s) by sharing information related to the 


telephone number(s) of the sender(s) against which complaint is made 


a) The Distributed Ledger for Complaints (DL-Complaints) having a history of the 
complainant and against whom complaints are being made used in conjunction with 
UCC_Detect_System would make it possible to precisely identify UTMs. 


b) The Authority has decided that in case of a complaint against a UTM also the OAP will 
examine CDRs in parallel to TAP, within one business day from the date of receipt of the 
complaint, to check the occurrence of communication that is under investigation. 


¢ Incase, the answer is no, then OAP will communicate to the TAP to inform the 
complainant about the closure of complaint in a manner prescribed in the CoP. 


¢ In case of the answer is yes, then OAP will further examined, within two 
business days, whether there are similar complaints or reports against the same 
sender. 


The action that is expedited to control UCC: 


1) 


li) 


If multiple complaints are received against the same sender, Usage Cap would be 
applied immediately, which can be restored after due investigation if there is no guilt. 
Sufficient time is given for concluding the investigation an opportunity is given to the 
sender who is kept under Usage Cap to defend themselves. The Authority decides that 
if there are complaints against the sender from ten or more recipients over a period of 
seven days preceding the date of receiving a complaint, then OAP will put the sender 
under Usage Cap and at the same time initiate investigation. Such restrictions will be in 
place till the investigation is complete or for thirty days from the date of effect of 
restrictions, whichever is earlier. 


If complaints are not received from multiple recipients then before taking action, more 
checks are done to find out whether the sender has sent only a few messages or made 
only a few calls and can not reasonably be considered as UTM. In view of this the 
Authority decides that where number of complaints are from less than ten recipients, 
the OAP will check from the previous thirty days data of UCC_Detect System whether 
suspected sender is involved in sending Commercial Communication in bulk or not 
(Definition of bulk may be by counting communications over a period of 24 hours, over 
a week and over a month). 


a. Incase, the answer is yes, the OAP will put sender under Usage Cap and at the same 
time initiate investigation. Such restrictions will be valid till investigation or thirty 
days from the date of effect of restrictions, whichever is earlier. 


b. Incase, the answer is no, OAP will warn such sender through appropriate means as 
provided for in CoPs and remove the usage cap. 


ili) The sender will be given the opportunity to represent his/her case before finally 
concluding the investigation. If the sender was found indulging in UCC in violation of 
regulations, he/she will be given warning for the first offense and the Usage Cap 
removed. If the violation is repeated a second time, Usage Cap is applied for the longer 
period and in case of third time, all resources should be disconnected except one which 
may be provided with Usage Cap to use minimum functional requirements for daily 
use. In view of this the Authority decides that OAP will issue notice, within three 
business days, to give opportunity to suspected sender(s) to represent his/her case and 
conclude investigation within thirty business days from the date of receipt of complaint 
and if sender is found to be indulging in sending UCC then OAP will take action against 
such sender as under: 


a. For the first instance of violation, the due warning shall be given. The first instance 
of the violation should include all the complaints against the sender within two 
business days after the date of receipt of the first complaint, against which the sender 
is to be warned. 

b. For the second instance of violation, Usage Cap is continued for a period of six 
months. The second instance of the violation will include all the complaints against 
the sender after the issuance of first warning within two business days after the date 
of receipt of the complaint against which second warning is being given to the 
sender. 


c. For third and subsequent instances of violations, all telecom resources of the sender 
are disconnected for a period up to two years. 


»» Every Access Provider shall formulate codes of practice (CoP-UCC_Detect) for system, 
functions, and process prescribed as follows: - 


1) Implementation details for detecting Unsolicited Commercial Communications related 
to suspicious unregistered telemarketing activity using Signature solution, deploying 
honeypots and other technical measures 


This classifies honeypot deployment scenarios into three broad categories based on the 
interaction level with the attackers: 


a) CDR-Only Honeypot 
b) Limited Interaction Honeypot 


c) Full Interaction Honeypot 


Apart from the first category, each scenario can be deployed with or without the voice 
recording feature. The attacker makes calls to the “honeypot numbers” included in the 
overall pool of numbers in their dial-out campaigns. 


Data collected in the honeypot — e.g. CDRs, voice recordings, etc. — would subsequently be 
stored to build intelligence reports of calls coming into honeypot numbers within a TSP 
network. The retention policy for storing these transactions should be consistent with other 
similar data types collected. 


Scenario 1: Call Detail Record Only Honeypot 
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In this scenario, TSPs do not provide call routing functionality and calls to the honeypot 
phone numbers are terminated within their own network. Various call completion 
behaviors, such as "not in service" recordings, no answer, busy, etc., are considered. After 
the call is made, the TSP would provide the Call Detail Records to the operator of the 
honeypot using a secure protocol such as an SSL or VPN connection. A CDR can be 
accompanied with additional information about how the call was handled (e.g., busy, seize 
the hangup, no answer or "not a working number" response). 


Scenario 2: Limited Interaction Honeypot 
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In a limited interaction scenario, TSPs provide call routing functionality and calls to the 
honeypot phone numbers are terminated at the honeypot-provided infrastructure. Call 
completion behaviors include non-termination (such as “not in service” recordings, no 
answer, busy, etc.) that are considered. 


Some of the options are as follows: 


10) 


Do not answer the call — A portion of calls are routed to a ring-no-answer, 
fast-busy, or number-not-in-service type message. 


Pick-up/hang-up — A portion of calls are picked up and immediately hung- 
up using an application on the honeypot server. 


Noise-only connection — A portion of calls are picked up via a server 
application with only white noise or similar background noise such as “static 
on the line” played for 60 seconds or so in various random volumes, patterns 
and/or duration. 


DTMF/touch tones — A portion of calls are picked up via a server application 
on the honeypot to mimic the consumer dialing DTMF (Dual Tone Multi- 
Frequency) tones; e.g., “Dial 1 to continue.” 


Injection of Jitter — Jitter, and latency are added to a portion of the calls to 
mimic poor connectivity. 


Fax-modem — A fax-modem tone is played back to mimic a fax-modem 
connection for a portion of the calls. 


Scenario 3: Full Interaction Honeypot 
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There are three levels of interactivity of a honeypot: 


I. 


IIL. 


Voicemail - A portion of calls are answered and recorded using voicemail 
announcements that indicate the calls are being recorded. These recordings are 
subsequently automatically processed using a variety of technologies to determine the 
origin of the call, type of call (ADAD or live voice) and other heuristic data relevant to 
the honeypot infrastructure. In all recording scenarios, an announcement indicating that 
the call is being recorded should be played before the recording commences. 
Announcement voices can be randomly generated with varying pitch, volume and voice 
annotations or other factors by making use of computer-generated voices. For example, 
a honeypot of 10,000 voice mailboxes can offer a range of 9,000 voice patterns, 
providing potential violators the sense that each mailbox is unique. Other standard or 
generic voicemail greetings generated by the TSP that indicate the call is being recorded 
can be used. In these scenarios, identical recording durations, including warnings of the 
message limits as well as other interactive voicemail features, is played through a TSP 
voicemail system. 


Interactive voice response (IVR) — A portion of calls are answered and recorded via an 
IVR system with a clear indication that the call is being recorded. 


Live person — Where the caller ID is under investigation, the call could be routed to an 
assigned person to allow for interaction with the suspected miscreant. Calls will be 
recorded in this case and the other party should be informed of the recording at the start 
of the call. Routing of calls to an officer could occur at random as well. 


2) Minimum standards of technical measures to share intelligence information, rules, criteria 
to detect suspected sources of spam: 


Spam can be described as unwanted or unsolicited electronic messages sent in bulk to a group 
of recipients. The messages are characterized as electronic, unsolicited, commercial, mass 
constitutes a growing threat mainly due to the following factors: 


1) The availability of low-cost bulk SMS plans 

2) Reliability (since the message reaches the mobile phone user) 

3) Low chance of receiving responses from some unsuspecting receivers 
4) The message can be personalized. 


A sample framework for detection of spam messages 


Content behavioral and network 
analysis 


Features based on behavior, contents 
and network 





¢ The input to the framework is to be originating from a mobile phone. 


¢ The system will collect contents and network information. Both the content and 
network data will be passed to the processing and feature extraction phase. 


¢ In the case of input from the mobile platform, the text message is passed to the 
pre-processing module where it is also represented using a minimal number of 
features. The features then extracted from the various components are passed 
to the machine learning predictive models that will have to be pre-trained for 
spam messages detection to identify the class category. 


¢ During the training phase of the spam account detection, the framework 
incorporates an evolutionary search algorithm to provide a minimal number of 
features for the spam account detection model. 


Different machine learning algorithms, which can be used for spam detection, are Naive 
Bayes, Support vector machine, Random Forest, Decision tree, Ada boost, and Logit boost. 


3) Approaches to detect and identify unregistered Unsolicited Commercial Communications 
sender(s), who are camouflaging themselves by fragmenting their activity across multiple 
phone numbers 


4) Approaches for deployment of honeypots to capture Unsolicited Commercial 
Communications voice call(s) 


Approaches for honeypot deployment into three broad categories based on the interaction level 
with the attackers: 


a) CDR-Only Honeypot 

b) Limited Interaction Honeypot 

c) Full Interaction Honeypot 

5) Approaches to detecting and identify the source(s) of dictionary attacks 


Dictionary attacks exploit a valid authentication mechanism, abusing the fact that users tend to 
choose weak credentials. It is complicated to detect such attacks, especially low-profile ones 
because an isolated attack attempt differs from a legitimate one only by intention and not any 
measurable properties. 


There are four tools for network-level detection of dictionary attacks 


1. SSH Monitor detects SSH attacks by matching attack signatures. It also comes with an 
observation that an attack is always preceded with a port scan and that most often two or 
more machines are targeted. 


2. SSH Cure is based on an observation that an SSH attack is divided into three phases with 
distinct flow properties: the scanning phase, the brute-force phase, and the die-off phase. 


3. Rdp Monitor is focused on a detection of RDP attacks. 


4. The honey scan uses the synergy of honeypots and network monitoring to detect various 
dictionary attacks. 


6) Timeline(s) for implementation of the functionality referred in the code of practice and 
operationalizing it 


Timeline diagrams present events during specific intervals shown chronologically along a 
line. Timelines are designed to provide a broad overview of a sequence of events in time. 
You don't need to go into detail, but links to events, information and images may be added 
as needed. 


Tips for Creating a Timeline 


¢ What does your timeline depict? Every timeline should have a title identifying the 
project or historic events it illustrates. Place a fitting title at the top of the page. 


Make the timeline. Decide what segment of time you want to illustrate. For projects, 
identify when work would begin and when it must be completed. Make a horizontal line 
or bar in the center of the page. Place the start and end dates at each end of the line 
going from left to right. 


Determine the scale of the timeline. Based upon the total duration of the time depicted, 
divide the timeline into equal, reasonable sections using small vertical line segments or 
dashes and label each accordingly. For example, if the timeline covers a year you may 
want to divide it into months, a day might be divided into hours and a century into 
decades. 


Missing time. If there is a period of time with no activity, you can skip a segment in the 
timeline or add a zigzag line to denote a time gap. 


Add events. Place small circles or points along the line wherever an event takes place 
or a task must be completed. Then attach a vertical line and extend it from the dot up or 
down, depending on how crowded the page is, and write the event in a box at the end 
of the line. If the timeline is very crowded, you can try using angled arrows or lines with 
varying lengths instead. An overcrowded timeline may also indicate that the scale of 
the timeline is too small. 


Add visuals. Use pictures to further illustrate an event or task on the timeline. This can 
add clarity and increase the visual appeal of your timeline. 


7) Such other matters as the Authority may deem fit, from time to time 


The Authority may issue advisory/ guideline(s) as deemed necessary from time to time for 
ensuring the safety. All such prohibitions and restrictions to be informed to the different 
departments immediately. 


Report of entities found to be engaged in making or causing to make silent calls, robocalls, 
abandoned calls or using telephone directory harvesting software to make Unsolicited 
Commercial Communications, as and when came to notice of the access provider, or as 
provided for in the regulations for the registered sender(s) with the access providers, on 
basis of following criteria: - 


a. Ratio of Abandon Calls to total attempted calls for a registered entity exceeding 
3% over a period of 24 Hours by an entity using Auto Dialer for Commercial 
Communications calls; 


b. Ratio of Silent Calls to total attempted calls for a registered entity exceeding 1% 
over a period of 24 hour by an entity using Auto Dialer for Commercial 
Communications Calls; 


c. Entity(ies) found to be using telephone number harvesting software for sending 
Unsolicited Commercial Communications are barred to use their network; 


ASSUMED GUIDELINES: 5 


(PERIODIC MONTHLY REPORTING- PMR) 


**The Assumed Guidelines does not represent a guide to the new Unsolicited commercial 
communication Code nor does it replace or supplement its provisions by imposing any new 
rights or obligations on the respective parties. Instead it is designed to complement the new Code 
by suggesting best practice to facilitate positive and productive engagement between all parties 
across a range of issues, roles and responsibilities. Whilst the Code of Practice provides some 
examples of best practice these are not intended to be exhaustive. 


General 


13. Access Provider who adopt this Assumed Guidelines will state so on their respective 
websites. 


14. Access Provider who adopt this Assumed Guidelines may also state so on their contracts. 


15. Access Provider who adopt this Assumed Guidelines has to adopt a Code of Practice for 
all new contracts, and other specified contracts, that are entered into after an effective date 
to be announced by the individual service provider. 


Preamble 


“Access Provider” is committed to the best possible use of its expertise/experience in order to 
satisfy the customers. Exceeding their expectations will always be the first priority in planning 
and delivering telecom services. 


Company Mission 


“Access Provider” believes that prompt response/co-operation is the first step towards 
development of long-term and prospective business relationship. We are committed to Quality 
Services for dynamic growth of the company. 


“Access Provider” is fully committed in fulfilling its Corporate Mission which is that: 


“ “Access Provider’ shall enable the smooth process of acquiring or registering the complaints 
and solving these registered complaints of the customers, and always perceive its services and 
customer’s complaint handling to be of the highest quality. Our customers shall view us as a 
trusted and honest company that always delivers on its promises”. 


Purpose of laying down the Assumed Guidelines for PMR. 
The purpose of laying down the Assumed Guidelines for PMR is to: 


16. Bring uniformity and transparency in the procedures being followed by Access Provider. 

17. Prescribe standards relating to acknowledgment of time and status. 

18. Measure the accuracy of solving the complaints within the provided time by the Access 
Provider from time to time and to compare them with the norms so as to assess the level 
of performance. 

19. Minimize the incidences of UCC complaints. 

20. Protect the interest of consumers of telecommunication services. 


Review 


The COP, which the Access Provider will create for complaints as given in TRAI regulation, may 
be reviewed by the Authority from time to time. The Authority, on reference from any affected 
party, and for good and sufficient reasons, may review and modify this regulation. 


Action Items for preparing Code of Practice for Periodic Monthly Reporting 
1. All the Access Providers shall maintain records of complaints on daily basis for each service 
area: - 


a. total number of complaints received on each day, from its customers as Terminating Access 
Provider, in each service area, against any registered sender; 
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b. total number of complaints transferred on each day, to Originating Access Provider(s) 


including itself, in each service area, against any registered sender; 
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c. total number of complaints to be resolved as an Originating Access Provider, according to 
the date of receipt of complaints; 
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d. total number of complaints rejected on account of insufficient details for further 
examination, according to the date of receipt of complaint; 
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e. total number of complaints to be resolved as an Originating Access Provider, according to 
the date of occurrence of unsolicited commercial communication; 
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Table for total number of complaints 


f. total number of senders against whom complaints were reported under clause (c); 
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g. total number of complaints out of reported complaints under clause (f), after completion of 
investigation, found to be valid complaint(s); 
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total number of senders out of reported senders under clause (h), who were put under 
restricted limits of usage provided for in Code(s) of Practice, as an interim measure to 
control unsolicited commercial communications during the investigation phase; 
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j. numbers of commercial communications sent by each sender, reported under clause(i); 
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k. total number of entities other than sender(s), after completion of investigation, found to be 
not compliant to the provisions provided for in these regulations or Code(s) of Practice and 
actions taken against them; 
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1. report total number of complaints on a day, for any sender, reported under clause(h); 
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All the Access Providers shall maintain records of complaints, from its customers and received 


from Terminating Access Provider(s), against unregistered sender(s) for sending unsolicited 


commercial communications on daily basis for each service area: 


a. total number of complaints received on each day, from its customers as Terminating Access 


Provider, in each service area, against any unregistered sender; 
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Periodic Monthly Reporting Table 
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b. total number of complaints transferred on each day, to Originating Access Provider(s) 


including itself, in each service area, against any unregistered sender; 
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c. total number of complaints to be resolved as an Originating Access Provider, according to 
the date of receipt of complaints; 
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d. total number of complaints rejected on account of insufficient details for further 
examination, according to the date of receipt of complaint; 
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e. total number of complaints to be resolved as an Originating Access Provider, according to 
the date of occurrence of unsolicited commercial communication; 
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Table for total number of complaints 


f. total number of senders against whom complaints were reported under clause (e); 
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Table for total number of complaints 


g. total number of complaints out of reported complaints under clause(e), after completion of 
investigation, found to be valid complaint(s); 
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ASSUMED GUIDELINES : 6 


( MIGRATION PLAN ) 


**The Assumed Guidelines does not represent a guide to the new Unsolicited commercial 
communication Code nor does it replace or supplement its provisions by imposing any new 
rights or obligations on the respective parties. Instead it is designed to complement the new Code 
by suggesting best practice to facilitate positive and productive engagement between all parties 
across a range of issues, roles and responsibilities. Whilst the Code of Practice provides some 
examples of best practice these are not intended to be exhaustive. 


General 


16. Access Provider who adopt this Assumed Guidelines will state so on their respective 
websites. 


17. Access Provider who adopt this Assumed Guidelines may also state so on their contracts. 


18. Access Provider who adopt this Assumed Guidelines has to adopt a Code of Practice for 
all new contracts, and other specified contracts, that are entered into after an effective date 
to be announced by the individual service provider. 


Preamble 


“Access Provider” is committed to the best possible use of its expertise/experience in order to 
satisfy the customers. Exceeding their expectations will always be the first priority in planning 
and delivering telecom services. 


Company Mission 


“Access Provider” believes that prompt response/co-operation is the first step towards 
development of long-term and prospective business relationship. We are committed to Quality 
Services for dynamic growth of the company. 


“Access Provider” is fully committed in fulfilling its Corporate Mission which is that: 


“ “Access Provider’ shall enable the smooth process of acquiring or registering the complaints 
and solving these registered complaints of the customers, and always perceive its services and 
customer’s complaint handling to be of the highest quality. Our customers shall view us as a 
trusted and honest company that always delivers on its promises”. 


Purpose of laying down the Assumed Guidelines for Migration Plan. 
The purpose of laying down the Assumed Guidelines for Migration Plan is to: 


21. Bring uniformity and transparency in the procedures being followed by Access Provider 
with regard to complaints registered by the users. 

22. Prescribe standards relating to acknowledgment of time and status. 

23. Protect the interest of consumers of telecommunication services. 


Review 


The COP, which the Access Provider will create for complaints as given in TRAI regulation may 
be reviewed by the Authority from time to time. The Authority, on reference from any affected 
party, and for good and sufficient reasons, may review and modify this regulation. 


Migration Plan 
1. Setting up Nodes and API’s 


Set up / creation of Master Node for access provider. 

Set up / creation of Nodes for each circle/ division according to the access 
provider supply chain. 

Connect all the nodes to the Master node with Master node being an observer node 
for all other nodes in the system. 


d. Activating input and edit access for all Nodes. 


Setting up access and credentials for API’s to interact with access provider central 
application infrastructure. 


2. Set up — DL Entities 


a. 


b. 
Cc. 


d. 


m. 


Stop new registration of telemarketers and new registration requests for headers of 
existing telemarketers till the activation of Telemarketer registration module. 

Set up a distributed ledger register named “DL — Entities”. 

Migrate data from Telemarketer registration module data of National Telemarketer 
Register (NTR) to DL-Entities and have observer node for TRAI. 

Send notification to all the telemarketers to fill in necessary fields and submit all 
the necessary or additional documents for identity verification. 

Start verification process of access provider parallel to the DL — Entity migration. 
Assign temporary headers for identity verified entities as soon as verification is 
done. 

Set up Telemarketer registration module for access provider. 

Set up deadline as 30 days for the telemarketers to submit the above mentioned 
information in point (d) and mark that as day 0. 

Send first alert for all telemarketers pending their identity verification on day 20. 
Send second alert for all telemarketers pending their identity verification on day 
22; 

Send a notification of dead line completion and an extension of deadline till day 
40 on day 30. 

Activate Telemarketer registration module for new telemarketers to register 
themselves according to the new regulations. 

Stop Entity migration on day 40. (Allow verification may be with a fine) 


3. Set up - DL Headers 


a. 


b. 
c. 


Stop Header registration of existing or newly registered telemarketers from day 0 
till day 45. 

Set up a distributed ledger register named “DL — Headers” on day 30. 

Set up reserved Headers list for state and central government entities and also for 
statutory bodies. 

Start Header assignment after the dead line of entity registration is passed. i.e day 
30. 

Make entries into DL-Headers with assigned headers for each entity. 

Set up telemarketer Header request module for access provider. 


Send notification to all verified telemarketers to check their assigned or rejected 
Headers. 

Set up a deadline till day 45 (15 days) for telemarketers to request new headers or 
get their existing headers to be registered. 

Send first alert to all entities with pending Header registration on day 40(10 days). 
Send final alert to all entities with pending Header registration on day 45 (15 days) 
with a notification of extended dead line till day 50(5 days). 

Activate telemarketer Header request module open for all telemarketers for 
requests of new Headers according to the new regulations. 

Stop existing Header assignment on day 50 and only accept new header 
registration. (Allow registration may be with a fine) 


4. Set up — DL Preference 


a. 


Freeze all changes from users in their preference on day 45 till migration of data to 
DL- Preference is completed. 


b. Set up a distributed ledger register named “DL — Preferences”. 


c. 
d. 


Start Migration of data from NCPR to DL-Preferences on day 45. 
Estimated time for migration 10 days (till day 55). 


5. Set up — DL Consent 


a. 
b. 
c. 


d. 


g. 


h. 


Freeze all changes in telemarketers consent list on day 55. 

Activate consent application client for telemarketers on day 55. 

Start migration of existing consents from telemarketers after verification for 
compliance with new regulations into DL- Consent. 

Send notification for all telemarketers to upload or verify the status of their 
consent management according to the new regulations on day 55. 

Set up a deadline till day 65(10 days) for consent verification. 

Send first alert for all telemarketers to upload their consents on day 60. 

Send final alert to all entities with pending consent verification on day 65 (10 
days) with a notification of extended dead line till day 70(5 days). 

Stop consent migration on day 70. (Allow consent upload may be with a fine). 


6. Set up Scrubbing Function 


a. 
b. 


c. 
d. 
e. 


Create API’s for interaction with DL’s of other access providers on day 65. 
Create API documentation for interaction for third party DL’s with access 
provider DL’s. 

Set up Scrubbing function on day 65. 

Estimated time for activation 5 days ( till day 70). 

Integration with Consent module day 70. 


7. Set up — DL Complaints 


a. 
b. 
c. 


Freeze all changes in complaints module on day 70. 
Set up distributed ledger register named “DL — Complaints”. 
Start migration of complaint module data to DL — Complaints on day 70. 


d. 


Estimated time for migration 5 days (till day 75). 


8. Set up Consent verification function. 


a. 
b. 
c. 


Set up consent verification module for telemarketers on day 75. 
Integrate Consent verification module with DL-Consent on day 75. 
Activate Consent verification module for telemarketers on day 75. 


9. Set up Content module. 


a. 
b. 
c. 
d. 


e 
f. 
8 


Set up content creation modules for telemarketers on day 76. 
Set up fixed content creation module on day 76. 

Set up variables creation module on day 76. 

Activate Content verification module on day 76. 

Activate fixed content verification module on day 76. 
Activate variables verification module on day 76. 


. Integrate Content module to Headers on day 76. 


10. Set up — User App. 


a. 
. Activate User preferences module on day 77. 


i. 


Set up User App deployment on day 77. 


Activate User call / sms logs on day 77. 


b 
c 
d. Activate User report module on day 77. 
e. 
f. 
g 
h 


Activate User Consent module on day 77. 
Integration of User app to DL- Preference on day 77. 


. Integration of User app to DL- Complaints on day 77. 
. Integration of User app to DL — Consents on day 77. 


Activation of User profile and settings with DND option on day 77. 


11. Set up Explorer permissions 


a. 


b. 


Cc. 


DL — Entities : TRAI — Observer node 

User — None 

OAP — Master node 

OAP (circle) — Publishing node 

TAP — Permissioned observer node 

Telemarketers — Self view node 
DL — Headers : TRAI — Observer node 

User — None 

OAP — Master node 

OAP (circle) — Publishing node 

TAP — Permissioned observer node 

Telemarketers — Self view node 
DL — Preference: TRAI — Observer node 

User — Self view node 

OAP — Master node 

OAP (circle) — None 

TAP — Scrubbing observer node 


Telemarketers — Scrubbing observer node 
d. DL— Consent : TRAI — Observer node 
User — Publishing Node 
OAP — Master node 
OAP (circle) — None 
TAP — Scrubbing observer node 
Telemarketers — Scrubbing observer node 
e. DL-—Complaints : TRAI — Observer node 
User — Publishing node 
OAP — Master node 
OAP (circle) — None 
TAP — Permissioned observer node 
Telemarketers — None 
f. Access to all permissions required on day 78. 


12. Set up — Delivery Functions 
a. Set up call delivery function on day 79. 
b. Set up sms delivery function on day 79. 
c. Integration of delivery functions into distributed ledgers on day 79. 


13. Set up — Honey pots 
a. Set up Honey pots with all the sms/call traffics on day 79. 
b. Set up abandon calls detection on 79. 
c. Set up short calls detection on 79. 
d. Set up IVRS verification module on 79. 
14. Set up — UCC detection 
a. Set up UCC detection module on day 80. 
b. Activation of UCC detection module on day 80. 
c. Integration on UCC detection module into distributed ledgers on day 80. 


15. Testing and Other Migrations. 
a. Testing module for system on day 81. 
b. Estimated time for intensive testing 9 days (till day 90). 
c. Integrations and miscellaneous issues till day 90. 
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